Preface

Move semantics, introduced with C++11, has become a hallmark of modern C++ programming. However, it also complicates the language in many ways. Even after several years of support, experienced programmers struggle with all the details of move semantics, style guides still recommend different consequences for programming even of trivial classes, and we still discuss semantic details in the C++ standards committee.

Whenever I have taught what I have learned about C++ move semantics so far, I have said, “Somebody has to write a book about all this,” and the usual answer was: “Yes, please do!” So, I finally did.

As always when writing a book about C++, I was surprised about the number of aspects to be taught, the situations to be clarified, and the consequences to be described. It really was time to write a book about all aspects of move semantics, covering all C++ versions from C++11 up to C++20. I learned a lot and I am sure you will too.

An Experiment

This book is an experiment in two ways:

• I am writing an in-depth book covering a complex core language feature without the direct help of a core language expert as a co-author. However, I can ask questions and I do.
• I am publishing the book myself on Leanpub and for printing on demand. That is, this book is written step by step and I will publish new versions as soon there is a significant improvement that makes the publication of a new version worthwhile.

The good thing is:

• You get the view of the language features from an experienced application programmer—somebody who feels the pain a feature might cause and asks the relevant questions to be able to motivate and explain the design and its consequences for programming in practice.
• You can benefit from my experience with move semantics while I am still writing.
• This book and all readers can benefit from your early feedback.

This means that you are also part of the experiment. So help me out: give feedback about flaws, errors, features that are not explained well, or gaps, so that we all can benefit from these improvements.

Versions of This Book

Because this book is written incrementally, the following is a history of the major updates (newest first):

• 2020-10-27: Several fixes (see errata)
• 2020-09-18: Using lambdas with template parameters (since C++20)
• 2020-09-15: Fix a bug with full specializations of universal references
• 2020-09-12: std::move() for data members
• 2020-09-10: Fixing deferred perfect returning
• 2020-09-09: Proof reading done and final fixes to go into print
• 2020-09-06: Helper trait is_nothrow_movable for abstract base classes
• 2020-09-06: Value category of (references to) functions
• 2020-09-05: Clarifications on auto&& including using it in C++20 functions
• 2020-08-29: Move assignments of objects to themselves
• 2020-08-28: Move semantics for std::pair<>, std::optional<>, threads, etc.
• 2020-08-28: Unique pointers, IOStreams, and other move-only types
• 2020-08-26: Several clarifications about universal references
• 2020-08-25: Using std::move() when calling member functions
• 2020-08-20: New chapter about move-only types
• 2020-08-19: Discussion of noexcept details
• 2020-08-18: New chapter about moving algorithms and iterators
• 2020-08-10: Description of move semantics for shared pointers
• 2020-08-10: Motivation for the reuse of moved-from objects and clarification of move assignments of objects to themselves
• 2020-08-09: Recommendation not to return by value with const
• 2020-07-27: Move semantics for strings and containers
• 2020-07-24: General remarks on using reference qualifiers
• 2020-07-23: Description of details of type deduction of universal references and reference collapsing for perfect forwarding
• 2020-07-07: Description of perfect returning for lambdas
• 2020-06-21: New chapter about perfect returning (with small fixes for perfect forwarding)
• 2020-06-12: Improvements of the chapter about “invalid” states
• 2020-06-08: New chapter about using noexcept
• 2020-06-06: Improvements of the chapter about invalid states
• 2020-05-03: Fixing of move semantics in class hierarchies
• 2020-04-29: Fixing of move semantics for classes and invalid states after review
• 2020-04-25: Fixing of code layout and missing figures in non-PDF versions
• 2020-04-22: New chapter about moved-from states
• 2020-04-13: Discussion of when you cannot avoid using std::move()
• 2020-02-01: Discussion of when automatically generated move operations are broken
• 2020-01-19: Constructors with universal references
• 2020-01-04: The initial published version of the book

Acknowledgments

First of all, I would like to thank you, the C++ community, for making this book possible. The incredible design of all the features of move semantics, the helpful feedback, and their curiosity are the basis for the evolution of a successful language. In particular, thanks for all the issues you told me about and explained and for the feedback you gave.

I would especially like to thank everyone who reviewed drafts of this book or corresponding slides and provided valuable feedback and clarification. These reviews increased the quality of the book significantly, again proving that good things need the input of many “wise guys.” Therefore, so far (this list is still growing) huge thanks to Javier Estrada, Howard Hinnant, Klaus Iglberger, Daniel Krügler, Marc Mutz, Aleksandr Solovev (alexolut), Peter Sommerlad, and Tony Van Eerd.

In addition, I would like to thank everyone in the C++ community and on the C++ standards committee. In addition to all the work involved in adding new language and library features, these experts spent many, many hours explaining and discussing their work with me, and they did so with patience and enthusiasm.

Special thanks go to the LaTeX community for a great text system and to Frank Mittelbach for solving my LaTeX issues (it was almost always my fault).

And finally, many thanks go to my proofreader, Tracey Duffy, who has done a tremendous job of converting my “German English” into native English.

About This Book

This book teaches C++ move semantics. Starting from the basic principles, it motivates and explains all features and corner cases of move semantics so that as a programmer, you can understand and use move semantics correctly. The book is valuable for those who are just starting to learn about move semantics and is essential for those who are using it already.

As usual for my books, the focus lies on the application of the new features in practice and the book will demonstrate how features impact day-to-day programming and how you can benefit from them in projects. This applies to both application programmers and programmers who provide generic frameworks and foundation libraries.

What You Should Know Before Reading This Book

To get the most from this book, you should already be familiar with C++. You should be familiar with the concepts of classes and references in general, and you should be able to write C++ programs using components such as IOStreams and containers from the C++ standard library. You should also be familiar with the basic features of “Modern C++,” such as auto or the range-based for loop.

However, you do not have to be an expert. My goal is to make the content understandable for the average C++ programmer who does not necessarily know all the details of the latest features. I will discuss basic features and review more subtle issues as the need arises.

This ensures that the text is accessible to experts and intermediate programmers alike.

Overall Structure of the Book

This book covers all aspects of C++ move semantics up to C++20. This applies to both language and library features as well as both features that affect day-to-day application programming and features for the sophisticated implementation of (foundation) libraries. However, the more general cases and examples usually come first.

The different chapters are grouped, so that didactically you should read the book from beginning to end. That is, later chapters usually rely on features introduced in earlier chapters. However, cross-references also help in specific subsequent topics, indicating where they refer to features and aspects introduced earlier.

The book therefore contains the following parts:

• Part I covers the basic features of move semantics (especially for non-generic code).
• Part II covers the features of move semantics for generic code (especially used in templates and generic lambdas).
• Part III covers the use of move semantics in the C++ standard library (giving also a good example of how to use move semantics in practice).

How to Read This Book

Do not be afraid by the number of pages in this book. As always with C++, things can become pretty complicated when you look into details (such as implementing templates). For a basic understanding, the first third of the book (Part I, especially chapters 1 to 5) is sufficient.

In my experience, the best way to learn something new is to look at examples. Therefore, you will find a lot of examples throughout the book. Some are just a few lines of code illustrating an abstract concept, whereas others are complete programs that provide a concrete application of the material. The latter kind of examples will be introduced by a C++ comment describing the file containing the program code. You can find these files on the website for this book at http://www.cppmove.com.

The Way I Implement

Note the following hints about the way I write code and comments.

Initializations

I usually use the modern form of initialization (introduced in C++11 as uniform initialization) with curly braces:

int i{42};
std::string s{"hello"};

This form of initialization, which is called brace initialization, has the following advantages:

• It can be used with fundamental types, class types, aggregates, enumeration types, and auto
• It can be used to initialize containers with multiple values
• It can detect narrowing errors (e.g., initialization of an int by a floating-point value)
• It cannot be confused with function declarations or calls

If the braces are empty, the default constructors of (sub)objects are called and fundamental data types are guaranteed to be initialized with 0/false/nullptr.

Error Terminology

I often talk about programming errors. If there is no special hint, the term error or a comment such as

...   // ERROR

means a compile-time error. The corresponding code should not compile (with a conforming compiler).

If I use the term runtime error, the program might compile but not behave correctly or result in undefined behavior (thus, it might or might not do what is expected).

Code Simplifications

I try to explain all features with helpful examples. However, to concentrate on the key aspects to be taught, I might often skip other details that should be part of code.

• Most of the time I use an ellipsis (“…”) to signal additional code that is missing. Note that I do not use code font here. If you see an ellipsis with code font, code must have these three dots as a language feature (such as for “typename...”).
• In header files I usually skip the preprocessor guards. All header files should have something like the following:

    #ifndef MYFILE_HPP
    #define MYFILE_HPP
    ...
    #endif  // MYFILE_HPP
  

  So, please beware and fix the code when using these header files in your projects.

The C++ Standards

C++ has different versions defined by different C++ standards.

The original C++ standard was published in 1998 and was subsequently amended by a technical corrigendum in 2003, which provided minor corrections and clarifications to the original standard. This “old C++ standard” is known as C++98 or C++03.

The world of “Modern C++” began with C++11 and was extended with C++14 and C++17. The international C++ standards committee now aims to issue a new standard every three years. Clearly, that leaves less time for massive additions, but it brings the changes to the broader programming community more quickly. The development of larger features, therefore, takes time and might cover multiple standards.

The next “Even more Modern C++” is already on the horizon, as introduced with C++20. Again, several ways to program will probably change. However, as usual, compilers need some time to provide the latest language features. At the time of writing this book, C++17 is usually the latest version supported by major compilers.

Fortunately, the basic principles of move semantics were all introduced with C++11 and C++14. For that reason, the code examples in this book should usually compile on recent versions of all major compilers. If special features introduced with C++17 or C++20 are discussed, I will mention that explicitly.

Example Code and Additional Information

You can access all example programs and find more information about this book from its website, which has the following URL:

http://www.cppmove.com

Feedback

I welcome your constructive input—both negative and positive. I have worked very hard to bring you what I hope you will find to be an excellent book. However, at some point I had to stop writing, reviewing, and tweaking to “release the new revision.” You may therefore find errors, inconsistencies, presentations that could be improved, or topics that are missing altogether. Your feedback gives me a chance to fix these issues, inform all readers about the changes through the book’s website, and improve any subsequent revisions or editions.

The best way to reach me is by email. You will find the email address at the website for this book:

http://www.cppmove.com

If you use the ebook, you might want to ensure to have the latest version of this book available (remember it is written and published incrementally). You should also check the book’s Web site for the currently known errata before submitting reports. In any case, refer to the publishing date of this version when giving feedback. The current publishing date is 2020-12-19 (you can also find it on page ii, the page directly after the cover).

Many thanks.

I Basic Features of Move Semantics

This part of the book introduces the basic features of move semantics that are not specific to generic programming (i.e., templates). They are particularly helpful for application programmers in their day-to-day programming and therefore every C++ programmer using Modern C++ should know them.

Move semantics features for generic programming are covered in Part II.

1. The Power of Move Semantics

This chapter demonstrates the basic principles and benefits of move semantics using a short code example.

1.1 Motivation for Move Semantics

To understand the basic principles of move semantics, let us look at the execution of a small piece of code, first without move semantics (i.e., compiled with an old C++ compiler that supports only C++03) and then with move semantics (compiled with a modern C++ compiler that supports C++11 or later).

1.1.1 Example with C++03 (Before Move Semantics)

Assume we have the following program:

#include <string>
#include <vector>

std::vector<std::string> createAndInsert()
{
  std::vector<std::string> coll;  // create vector of strings
  coll.reserve(3);                // reserve memory for 3 elements
  std::string s = "data";         // create string object

  coll.push_back(s);              // insert string object
  coll.push_back(s+s);            // insert temporary string
  coll.push_back(s);              // insert string

  return coll;                    // return vector of strings
}

int main()
{
  std::vector<std::string> v;     // create empty vector of strings
  //...
  v = createAndInsert();          // assign returned vector of strings
  //...
}

Let us look at the individual steps of the program (inspecting both the stack and the heap) when we compile this program with a C++ compiler that does not support move semantics.

• First, in main(), we create the empty vector v:

    std::vector<std::string> v;
  

  which is placed on the stack as an object that has 0 as the number of elements and no memory allocated for elements.

• Then, we call

    v = createAndInsert();
  

  where we create another empty vector coll on the stack and reserve memory for three elements on the heap:

    std::vector<std::string> coll;
    coll.reserve(3);
  

  The allocated memory is not initialized because the number of elements is still 0.

• Then, we create a string initialized with "data":

    std::string s = "data";
  

  A string is something like a vector with char elements. Essentially, we create an object on the stack with a member for the number of characters (having the value 4) and a pointer to the memory for the characters.¹

  After this statement, the program has the following state: we have three objects on the stack: v, coll, and s. Two of them, coll and s, have allocated memory on the heap:²

  

• The next step is the command to insert the string into the vector coll:

    coll.push_back(s);
  

  All containers in the C++ standard library have value semantics, which means that they create copies of the values passed to them. As a result, we get a first element in the vector, which is a full (deep) copy of the passed value/object s:

  

  So far, we have nothing to optimize in this program. The current state is that we have two vectors, v and coll, and two strings, s and its copy, which is the first element in coll. They should all be separate objects with their own memory for the value, because modifying one of them should not impact any of the other objects.

• Let us now look at the next statement, which creates a new temporary string and again inserts it into the vector:

    coll.push_back(s+s);
  

  This statement is performed in three steps:

  1. We create the temporary string s+s:

     

  2. We insert this temporary string into the vector coll. As always, the container creates a copy of the passed value, which means that we create a deep copy of the temporary string, including allocating memory for the value:

     

  3. At the end of the statement, the temporary string s+s is destroyed because we no longer need it:

     

  Here, we have the first moment where we generate code that is not performing well: we create a copy of a temporary string and destroy the source of the copy immediately afterwards, which means that we unnecessarily allocate and free memory that we could have just moved from the source to the copy.

• With the next statement, again we insert s into coll:

    coll.push_back(s);
  

  Again, coll copies s:

  

  This is also something to improve: because the value of s is no longer needed some optimization could use the memory of s as memory for the new element in the vector instead.

• At the end of createAndInsert() we come to the return statement:

      return coll;
    }
  

  Here, the behavior of the program becomes a bit more complicated. We return by value (the return type is not a reference), which should be a copy of the value in the return statement, coll. Creating a copy of coll means that we have to create a deep copy of the whole vector with all of its elements. Thus, we have to allocate heap memory for the array of elements in the vector and heap memory for the value each string allocates to hold its value. Here, we would have to allocate memory 4 times.

  However, since at the same time coll is destroyed because we leave the scope where it is declared, the compiler is allowed to perform the named return value optimization (NRVO). This means that the compiler can generate code so that coll is just used as the return value.

  This optimization is allowed even if this would change the functional behavior of the program. If we had a print statement in the copy constructor of a vector or string, we would see that the program no longer has the output from the print statement. This means that this optimization changes the functional behavior of the program. However, that is OK, because we explicitly allow this optimization in the C++ standard even if it has side effects. Nobody should expect that a copy is done here, in the same way that nobody should expect that it is not, either. It is simply up to the compiler whether the named return value optimization is performed.

  Let us assume that we have the named return value optimization. In that case, at the end of the return statement, coll now becomes the return value and the destructor of s is called, which frees the memory allocated when it was declared:

  

• Finally, we come to the assignment of the return value to v:

    v = createAndInsert();
  

  Here, we really get behavior that can be improved: the usual assignment operator has the goal of giving v the same value as the source value that is assigned. In general, any assigned value should not be modified and should be independent from the object that the value was assigned to. So, the assignment operator will create a deep copy of the whole return value:

  

  However, right after that, we no longer need the temporary return value and we destroy it:

  

  Again, we create a copy of a temporary object and destroy the source of the copy immediately afterwards, which means that we again unnecessarily allocate and free memory. This time it applies to four allocations, one for the vector and one for each string element.

For the state of this program after the assignment in main(), we allocated memory ten times and released it six times. The unnecessary memory allocations were caused by:

• Inserting a temporary object into the collection
• Inserting an object into the collection where we no longer need the value
• Assigning a temporary vector with all its elements

We can more or less avoid these performance penalties. In particular, instead of the last assignment, we could do the following:

• Pass the vector as an out parameter:

    createAndInsert(v);  // let the function fill vector v
  

• Use swap():

    createAndInsert().swap(v);
  

However, the resulting code looks uglier (unless you see some beauty in complex code) and there is not really a workaround when inserting a temporary object.

Since C++11, we have another option: compile and run the program with support for move semantics.

1.1.2 Example Since C++11 (Using Move Semantics)

Let us now recompile the program with a modern C++ compiler (C++11 or later) that supports move semantics:

#include <string>
#include <vector>

std::vector<std::string> createAndInsert()
{
  std::vector<std::string> coll;  // create vector of strings
  coll.reserve(3);                // reserve memory for 3 elements
  std::string s = "data";         // create string object

  coll.push_back(s);              // insert string object
  coll.push_back(s+s);            // insert temporary string
  coll.push_back(std::move(s));   // insert string (we no longer need the value of s)

  return coll;                    // return vector of strings
}

int main()
{
  std::vector<std::string> v;     // create empty vector of strings
  //...
  v = createAndInsert();          // assign returned vector of strings
  //...
}

There is a small modification, though: we add a std::move() call when we insert the last element into coll. We will discuss this change when we come to this statement. Everything else is as before.

Again, let us look at the individual steps of the program by inspecting both the stack and the heap.

• First, in main(), we create the empty vector v, which is placed on the stack with 0 elements:

    std::vector<std::string> v;
  

• Then, we call

    v = createAndInsert();
  

  where we create another empty vector coll on the stack and reserve uninitialized memory for three elements on the heap:

    std::vector<std::string> coll;
    coll.reserve(3);
  

• Then, we create the string s initialized with "data" and insert it into coll again:

    std::string s = "data";
    coll.push_back(s);
  

  So far, there is nothing to optimize and we get the same state as with C++03:

  

  We have two vectors, v and coll, and two strings, s and its copy, which is the first element in coll. They should all be separate objects with their own memory for the value, because modifying one of them should not impact any of the other objects.

• This is where things change. First, let us look at the statement that creates a new temporary string and inserts it into the vector:

    coll.push_back(s+s);
  

  Again, this statement is performed in three steps:

  1. We create the temporary string s+s:

     

  2. We insert this temporary string into the vector coll. However, here something different happens now: we steal the memory for the value from s+s and move it to the new element of coll.

     

     This is possible because since C++11, we can implement special behavior for getting a value that is no longer needed. The compiler can signal this fact because it knows that right after performing the push_back() call, the temporary object s+s will be destroyed. So, we call a different implementation of push_back() provided for the case when the caller no longer needs that value. As we can see, the effect is an optimized implementation of copying a string where we no longer need the value: instead of creating an individual deep copy, we copy both the size and the pointer to the memory. However, that shallow copy is not enough; we also modify the temporary object s+s by setting the size to 0 and assigning the nullptr as new value. Essentially, s+s is modified so that it gets the state of an empty string. The important point is that it no longer owns its memory. And that is important because we still have a third step in this statement.

  3. At the end of the statement, the temporary string s+s is destroyed because we no longer need it. However, because the temporary string is no longer the owner of the initial memory, the destructor will not free this memory.

     

  Essentially, we optimize the copying so that we move the ownership of the memory for the value of s+s to its copy in the vector.

  This is all done automatically by using a compiler that can signal that an object is about to die, so that we can use new implementations to copy a string value that steals the value from the source. It is not a technical move; it is a semantic move implemented by technically moving the memory for the value from the source string to its copy.

• The next statement is the statement we modified for the C++11 version. Again, we insert s into coll, but the statement has changed by calling std::move() for the string s that we insert:

    coll.push_back(std::move(s));
  

  Without std::move(), the same would happen as with the first call of push_back(): the vector would create a deep copy of the passed string s. However, in this call, we have marked s with std::move(), which semantically means “I no longer need this value here.” As a consequence, we have another call of the other implementation of push_back(), which was used when we passed the temporary object s+s. The third element steals the value by moving the ownership of the memory for the value from s to its copy:

  

  Note the following two very important things to understand about move semantics:

  • std::move(s) only marks s to be movable in this context. It does not move anything. It only says, “I no longer need this value here.” It allows the implementation of the call to benefit from this mark by performing some optimization when copying the value, such as stealing the memory. Whether the value is moved is something the caller does not know.
  • However, an optimization that steals the value has to ensure that the source object is still in a valid state. A moved-from object is neither partially nor fully destroyed. The C++ standard library formulates this for its types as follows: after an operation called for an object marked with std::move(), the object is in a valid but unspecified state.

    That is, after calling

      coll.push_back(std::move(s));
    

    it is guaranteed that s is still a valid string. You can do whatever you want as long as it is valid for any string where you do not know the value. It is like using a string parameter where you do not know which value was passed.

    Note that it is also not guaranteed that the string either has its old value or is empty. The value it has is up to the implementers of the (library) function. In general, implementers can do with objects marked with std::move() whatever they like, provided they leave the object in a valid state. There are good reasons for this guarantee, which will be discussed later.

• Again, at the end of createAndInsert() we come to the return statement:

      return coll;
    }
  

  It is still up to the compiler whether it generates code with the named return value optimization, which would mean that coll just becomes the return value. However, if this optimization is not used, the return statement is still cheap, because again we have a situation where we create an object from a source that is about to die. That is, if the named return value optimization is not used, move semantics will be used, which means that the return value steals the value from coll. At worst, we have to copy the members for size, capacity, and the pointer to the memory (in total, usually 12 or 24 bytes) from the source to the return value and assign new values to these members in the source.

  Let us assume that we have the named return value optimization. In that case, at the end of the return statement, coll now becomes the return value and the destructor of s is called, which no longer has to free any memory because it was moved to the third element of coll:

  

• So, finally, we come to the assignment of the return value to v:

    v = createAndInsert();
  

  Again, we can benefit from move semantics now because we have a situation we have already seen: we have to copy (here, assign) a value from a temporary return value that is about to die.

  Now, move semantics allows us to provide a different implementation of the assignment operator for a vector that just steals the value from the source vector:

  

  Again, the temporary object is not (partially) destroyed. It enters into a valid state but we do not know its value.

  However, right after the assignment, the end of the statement destroys the (modified) temporary return value:

  

At the end we are in the same state as before using move semantics but something significant has changed: we saved six allocations and releases of memory. All unnecessary memory allocations no longer took place:

• Allocations for inserting a temporary object into the collection
• Allocations for inserting a named object into the collection, when we use std::move() to signal that we no longer need the value
• Allocations for assigning a temporary vector with all its elements

In the second case, the optimization was done with our help. By adding std::move(), we had to say that we no longer needed the value of s there. All other optimizations happened because the compiler knows that an object is about to die, meaning that it can call the optimized implementation, which uses move semantics.

This means that returning a vector of strings and assigning it to an existing vector is no longer a performance issue. We can use a vector of strings naively like an integral type and get much better performance. In practice, recompiling code with move semantics can improve speed by 10% to 40% (depending on how naive the existing code was).

1.2 Implementing Move Semantics

Let us use the previous example to see where and how move semantics is implemented.

Before move semantics was implemented, class std::vector<> had only one implementation of push_back() (the declaration of vector is simplified here):

template<typename T>
class vector {
  public:
    ...
    // insert a copy of elem:
    void push_back (const T& elem);
    ...
};

There was only one way to pass an argument to push_back() binding it to a const reference. push_back() is implemented in a way that the vector creates an internal copy of the passed argument without modifying it.

Since C++11, we have a second overload of push_back():

template<typename T>
class vector {
  public:
    ...
    // insert a copy of elem:
    void push_back (const T& elem);

    // insert elem when the value of elem is no longer needed:
    void push_back (T&& elem);
    ...
};

The second push_back() uses a new syntax introduced for move semantics. We declare the argument with two & and without const. Such an argument is called an rvalue reference.³ “Ordinary references” that have only one & are now called lvalue references. That is, in both calls we pass the value to be inserted by reference. However, the difference is as follows:

• With push_back(const T&), we promise not to modify the passed value.

  This function is called when the caller still needs the passed value.

• With push_back(T&&), the implementation can modify the passed argument (therefore it is not const) to “steal” the value. The semantic meaning is still that the new element receives the value of the passed argument but we can use an optimized implementation that moves the value into the vector.

  This function is called when the caller no longer needs the passed value. The implementation has to ensure that the passed argument is still in a valid state. However, the value may be changed. Therefore, after calling this, the caller can still use the passed argument as long as the caller does not make any assumption about its value.

However, a vector does not know how to copy or move an element. After making sure that the vector has enough memory for the new element, the vector delegates the work to the type of the elements.

In this case, the elements are strings. So, let us see what happens if we copy or move the passed string.

1.2.1 Using the Copy Constructor

push_back(const T&) for the traditional copy semantics calls the copy constructor of the string class, which initializes the new element in the vector. Let us look at how this is implemented. The copy constructor of a very naive implementation of a string class would look like this:⁴

class string {
  private:
    int len;                       // current number of characters
    char* data;                    // dynamic array of characters

  public:
    // copy constructor: create a full copy of s:
    string (const string& s)
     : len{s.len} {                // copy number of characters
        if (len > 0) {                  // if not empty
          data = new char[len+1];       // - allocate new memory
          memcpy(data, s.data, len+1);  // - and copy the characters
        }
    }
    ...
};

Given that we call this copy constructor for a string that has the value "data":

std::string a = "data";
std::string b = a;       // create b as a copy of a

after initializing the string a as follows:

the copy constructor above would copy the member len for the number of characters but assign new memory for the value to the data pointer and copy all characters from the source a (passed as s) to the new string:

1.2.2 Using the Move Constructor

push_back(T&&) for the new move semantics calls a corresponding new constructor, the move constructor. This is the constructor that creates a new string from an existing string, where the value is no longer needed. As usual with move semantics, the constructor is declared with a non-const rvalue reference (&&) as its parameter:

class string {
  private:
    int len;                       // current number of characters
    char* data;                    // dynamic array of characters

  public:
    ...
    // move constructor: initialize the new string from s (stealing the value):
    string (string&& s)
     : len{s.len}, data{s.data} {  // copy number of characters and pointer to memory
        s.data = nullptr;          // release the memory for the source value
        s.len = 0;                 // and adjust number of characters accordingly
    }
    ...
};

Given the situation from the copy constructor above:

we can call this constructor for a string as follows:

std::string c = std::move(b);  // init c with the value of b (no longer needing its value here)

The move constructor first copies both the members len and data, meaning that the new string gets ownership of the value of b (passed as s).

However, this is not enough, because the destructor of b would free the memory. Therefore, we also modify the source string to lose its ownership of the memory and bring it into a consistent state representing the empty string:

The effect is that c now has the former value of b and that b is the empty string. Again, note that the only guarantee is that b is subsequently in a valid but unspecified state. Depending on the way the move constructor is implemented in a C++ library, it might not be empty (but it usually is because this is the easiest and best way to improve performance here).

1.3 Copying as a Fallback

We saw that by using temporary objects or marking objects with std::move() we can enable move semantics. Functions providing special implementations (by taking non-const rvalue references) can optimize the copying of a value by “stealing” the value from the source. However, if there is no optimized version of a function for move semantics, then the usual copying is used as a fallback.

For example, assume a container class like vector lacks the second overload of push_back():

template<typename T>
class MyVector {
  public:
    ...
    void push_back (const T& elem);  // insert a copy of elem
    ...    // no other push_back() declared
};

We can still pass a temporary object or an object marked with std::move():

MyVector<std::string> coll;
std::string s{"data"};
...
coll.push_back(std::move(s));  // OK, uses copy semantics

The rule is that for a temporary object or an object marked with std::move(), if available, a function declaring the parameter as an rvalue reference is preferred. However, if no such function exists, the usual copy semantics is used. That way, we ensure that the caller does not have to know whether an optimization exists. The optimization might not exist because:

• The function/class was implemented before move semantics was supported or without having move semantics support in mind
• There is nothing to optimize (a class with only numeric members would be an example of that)

For generic code, it is important that we can always mark an object with std::move() if we no longer need its value. The corresponding code compiles even if there is no move semantics support.

For the same reason, you can even mark objects of a fundamental data type such as int (or a pointer) with std::move(). The usual value semantics copying the value (the address) will still be used:

std::vector<int> coll;
int x{42};
...
coll.push_back(std::move(x));   // OK, but copies x (std::move() has no effect)

1.4 Move Semantics for const Objects

Finally, note that objects declared with const cannot be moved because any optimizing implementation requires that the passed argument can be modified. We cannot steal a value if we are not allowed to modify it.

With the usual overloads of push_back():

template<typename T>
class vector {
  public:
    ...
    // insert a copy of elem:
    void push_back (const T& elem);

    // insert elem when the value of elem is no longer needed:
    void push_back (T&& elem);
    ...
};

the only valid function to call for const objects is the first overload of push_back() with the const& parameter:

std::vector<std::string> coll;
const std::string s{"data"};
...
coll.push_back(std::move(s));  // OK, calls push_back(const std::string&)

That means that a std::move() for const objects essentially has no effect.

In principle, we could provide a special overload for this case by declaring a function taking a const rvalue reference. However, this makes no semantic sense. Again, the const lvalue reference overload serves as a fallback to handle this case.

1.4.1 const Return Values

The fact that const disables move semantics also has consequences for declaring return types. A const return value cannot be moved.

Therefore, since C++11, it is no longer good style to return by value with const (as some style guides have recommended in the past). For example:

const std::string getValue();

std::vector<std::string> coll;
...
coll.push_back(getValue());  // copies (because the return value is const)

When returning by value, do not declare the return value as a whole to be const. Use const only to declare parts of your return type (such as the object a returned reference or pointer refers to):

const std::string  getValue();  // BAD: disables move semantics for return values
const std::string& getRef();    // OK
const std::string* getPtr();    // OK

1.5 Summary

• Move semantics allows us to optimize the copying of objects, where we no longer need the value. It can be used implicitly (for unnamed temporary objects or local return values) or explicitly (with std::move()).
• std::move() means I no longer need this value here. It marks the object as movable. An object marked with std::move() is not (partially) destroyed (the destructor still will be called).
• By declaring a function with a non-const rvalue reference (such as std::string&&), you define an interface where the caller semantically claims that it no longer needs the passed value. The implementer of the function can use this information to optimize its task by “stealing” the value or do any other modification with the passed argument. Usually, the implementer also has to ensure that the passed argument is in a valid state after the call.
• Moved-from objects of the C++ standard library are still valid objects, but you no longer know their value.
• Copy semantics is used as a fallback for move semantics (if copy semantics is supported). If there is no implementation taking an rvalue reference, any implementation taking an ordinary const lvalue reference (such as const std::string&) is used. This fallback is then used even if the object is explicitly marked with std::move().
• Calling std::move() for a const object usually has no effect.
• If you return by value (not by reference), do not declare the return value as a whole to be const.

2. Core Features of Move Semantics

After the first motivating example, this chapter discusses the basic features of move semantics.

2.1 Rvalue References

To support move semantics we introduce a new type of reference: rvalue references. Let us discuss what they are and how to use them.

2.1.1 Rvalue References in Detail

Rvalue references are declared with two ampersands. Just as ordinary references, which are declared with one ampersand and are now called lvalue references, rvalue references refer to an existing object that has to be passed as an initial value. However, according to their semantic meaning, rvalue references can refer only to a temporary object that does not have a name or to an object marked with std::move():

std::string returnStringByValue();       // forward declaration
...
std::string s{"hello"};
...
std::string&& r1{s};                      // ERROR
std::string&& r2{std::move(s)};           // OK
std::string&& r3{returnStringByValue()};  // OK, extends lifetime of return value

The name rvalue reference comes from the fact that these objects can usually refer only to rvalues, a value category for temporary objects that do not have a name and objects marked with std::move().

As usual for successful initializations of references from return values, references extend the lifetime of the return value until the end of the lifetime of the reference (ordinary const lvalue references already had this behavior).

The syntax used to initialize the reference is irrelevant. You can use the equal sign, braces, or parentheses:

std::string s{"hello"};
...
std::string&& r1 = std::move(s);          // OK, rvalue reference to s
std::string&& r2{std::move(s)};           // OK, rvalue reference to s
std::string&& r3(std::move(s));           // OK, rvalue reference to s

All these references have the semantics of “we can steal/modify the object we refer to, provided the state of the object remains a valid state.” Technically, these semantics are not checked by compilers, so we can modify an rvalue reference as we can do with any non-const object of the type. We might also decide not to modify the value. That is, if you have an rvalue reference to an object, the object might receive a different value (which might or might not be the value of a default-constructed object) or it might keep its value.

As we have seen, move semantics allows us to optimize using a value of a source that no longer needs the value. If compilers automatically detect that a value is used from an object that is at the end of its lifetime, they will automatically switch to move semantics. This is the case when:

• We pass the value of a temporary object that will automatically be destroyed after the statement.
• We pass a non-const object marked with std::move().

2.1.2 Rvalue References as Parameters

When we declare a parameter to be an rvalue reference, it has exactly the behavior and semantics as introduced above:

• The parameter can bind only to a temporary object that does not have a name or to an object marked with std::move().
• According to the semantics of rvalue references:
  • The caller claims that it is no longer interested in the value. Therefore, you can modify the object the parameter refers to.
  • However, the caller might still be interested in using the object. Therefore, any modification should keep the referenced object in a valid state.

For example:

void foo(std::string&& rv);  // takes only objects where we no longer need the value
...
std::string s{"hello"};
...
foo(s);                      // ERROR
foo(std::move(s));           // OK, value of s might change
foo(returnStringByValue());  // OK

You can use a named object after passing it with std::move() but usually you should not. The recommended programming style is to no longer use an object after a std::move():

void foo(std::string&& rv);  // takes only objects where we no longer need the value
...
std::string s{"hello"};
...
foo(std::move(s));           // OK, value of s might change
std::cout << s << '\n';      // OOPS, you don't know which value is printed
foo(std::move(s));           // OOPS, you don't know which value is passed
s = "hello again";           // OK, but rarely done
foo(std::move(s));           // OK, value of s might change

For both lines marked with “OOPS,” the call is technically OK as long as you make no assumption about the current value of s. Printing out the value is therefore fine, although usually not very useful.

2.2 std::move()

If you have an object for which the lifetime does not end when you use it, you can mark it with std::move() to express “I no longer need this value here.” std::move() does not move; it only sets a temporary marker in the context where the expression is used:

void foo1(const std::string& lr);  // binds to the passed object without modifying it
void foo1(std::string&& rv);       // binds to the passed object and might steal/modify the va\
lue
...
std::string s{"hello"};
...
foo1(s);                           // calls the first foo1(), s keeps its value
foo1(std::move(s));                // calls the second foo1(), s might lose its value

Objects marked with std::move() can still be passed to a function that takes an ordinary const lvalue reference:

void foo2(const std::string& lr);  // binds to the passed object without modifying it
...                                 // no other overload of foo2()
std::string s{"hello"};
...
foo2(s);                           // calls foo2(), s keeps its value
foo2(std::move(s));                // also calls foo2(), s keeps its value

Note that an object marked with std::move() cannot be passed to a non-const lvalue reference:

void foo3(std::string&);           // modifies the passed argument
...
std::string s{"hello"};
...
foo3(s);                           // OK, calls foo3()
foo3(std::move(s));                // ERROR: no matching foo3() declared

Note that it does not make sense to mark a dying object with std::move(). In fact, this can even be counterproductive for optimizations.

2.2.1 Header File for std::move()

std::move() is defined as a function in the C++ standard library. Therefore, to use it, you have to include the header file <utility> where it is defined:

#include <utility>    // for std::move()

Programs using std::move() usually compile without including this header file, because in practice almost all header files include <utility>. However, no standard header file is required to include utility. Therefore, when using std::move(), you should explicitly include <utility> to make your program portable.

2.2.2 Implementation of std::move()

std::move() is nothing but a static_cast to an rvalue reference. You can achieve the same effect by calling static_cast manually as follows:

foo(static_cast<decltype(obj)&&>(obj));  // same effect as foo(std::move(obj))

Therefore, we could also write:

std::string s;
...
foo(static_cast<std::string&&>(s));     // same effect as foo(std::move(s))

Note that the static_cast does a bit more than only changing the type of the object here. It also enables the object to be passed to an rvalue reference (remember that passing objects with names to rvalue references is usually not allowed). We will discuss this in detail in the chapter about value categories.

2.3 Moved-From Objects

After a std::move(), moved-from objects are not (partially) destroyed. They are still valid objects for which at least the destructor will be called. However, they should also be valid in the sense that they have a consistent state and all operations work as expected. The only thing you do not know is their value. It is like using a parameter of the type where you have no clue which value was passed.

2.3.1 Valid but Unspecified State

The C++ standard library guarantees that moved-from objects are in a valid but unspecified state.

Consider the following code:

std::string s;
...
coll.push_back(std::move(s));

After passing s with std::move() you can ask for the number of characters, print out the value, or even assign a new value. However, you cannot print the first character or any other character without checking the number of characters first:

foo(std::move(s));               // keeps s in a valid but unclear state

std::cout << s << '\n';          // OK (don't know which value is written)
std::cout << s.size() << '\n';   // OK (writes current number of characters)
std::cout << s[0] << '\n';       // ERROR (potentially undefined behavior)
std::cout << s.front() << '\n';  // ERROR (potentially undefined behavior)
s = "new value";                 // OK

Although you do not know the value, the string is in a consistent state. For example, s.size() will return the number of characters so that you can iterate over all valid indexes:

foo(std::move(s));               // keeps s in a valid but unclear state

for (int i = 0; i < s.size(); ++i) {
  std::cout << s[i];             // OK
}

For user-defined types you should also ensure that moved-from objects are in a valid state, which sometimes requires the declaration or implementation of move operations. The chapter Moved-From States will discuss this in detail.

2.3.2 Reusing Moved-From Objects

You might wonder why moved-from objects are still valid objects and are not (partially) destroyed. The reason is that there are useful applications of move semantics where it makes sense to use moved-from objects again.

For example, consider code where we read line-by-line strings from a stream and move them into a vector:

std::vector<std::string> allRows;
std::string row;
while (std::getline(myStream, row)) {  // read next line into row
  allRows.push_back(std::move(row));   // and move it to somewhere
}

Each time after we read a line into row, we use std::move() to move the value of row into the vector of all rows. Then, std::getline() uses the moved-from object row again to read the next line into it.

As a second example, consider a generic function that swaps two values:

template<typename T>
void swap(T& a, T& b)
{
  T tmp{std::move(a)};
  a = std::move(b);     // assign new value to moved-from a
  b = std::move(tmp);   // assign new value to moved-from b
}

Here, we move the value of a into a temporary object to be able to move-assign the value of b afterwards. The moved-from object b then receives the value of tmp, which is the former value of a.

Code like this is used in sorting algorithms for example, where we move the values of the different elements around to bring them into a sorted order. Assigning new values to moved-from objects happens there all the time. The algorithm might even use the sorting criterion for such a moved-from object.

In general, moved-from objects should be valid objects that can be destroyed (the destructor should not fail), reused to get other values, and support all other operations objects their type supports without knowing the value. The chapter Moved-From States will discuss this in detail.

2.3.3 Move Assignments of Objects to Themselves

The rule that moved-from objects are in a valid but unspecified state usually also applies to objects after a direct or indirect self-move.

For example, after the following statement, object x is usually valid without its value being known:

x = std::move(x);   // afterwards x is valid but has an unclear value

Again, the C++ standard library guarantees that for its objects.⁵ User-defined types should usually also provide this guarantee, but sometimes you have to implement something to fix the default-generated moved-from states.

2.4 Overloading by Different References

After introducing rvalue references, we now have three major ways of call-by-reference:

• void foo(const std::string& arg)
  
  takes the argument as const lvalue reference.

  This means that you have only read access to the passed argument. Note that you can pass everything to a function declared that way if the type fits:

  • A modifiable named object
  • A const named object
  • A temporary object that does not have a name
  • An object marked with std::move()

  The semantic meaning is that we give foo() read access to the passed argument. The parameter is what we call an in parameter.

• void foo(std::string& arg)
  
  takes the argument as non-const lvalue reference.

  This means that you have write access to the passed argument. Note that you can no longer pass everything to a function declared that way even if the type fits. You can only pass:

  • A modifiable named object

  For all other arguments, the call does not compile.

  The semantic meaning is that we give foo() read/write access to the passed argument. The parameter is what we call an out or in/out parameter.

• void foo(std::string&& arg)
  
  takes the argument as non-const rvalue reference.

  This also means that you have write access to the passed argument. However, again you have restrictions on what you can pass. You can only pass:

  • A temporary object that does not have a name
  • An non-const object marked with std::move()

  The semantic meaning is that we give foo() write access to the passed argument to steal the value. It is an in parameter with the additional constraint that the caller no longer needs the value.

Note that rvalue references bind to other arguments than non-const lvalue references. Therefore, we had to introduce a new syntax and could not just implement move semantics as a different way of functions that modify passed arguments.

2.4.1 const Rvalue References

Technically, there is a fourth way of call-by-reference:

• void foo(const std::string&& arg)
  
  takes the argument as const rvalue reference.

  This also means that you have read access to the passed argument. Here, the restrictions would be that you can only pass:

  • A temporary object that does not have a name
  • A const or non-const object marked with std::move()

However, there is no useful semantic meaning of this case. As an rvalue reference, stealing the value is allowed, but being const, we disable any modification of the passed argument. This is a contradiction in itself.

Nevertheless, creating objects with this behavior is quite easy: Simply mark a const object with

std::move():

const std::string s{"data"};
...
foo(std::move(s));    // would call a function declared as const rvalue reference

This might happen indirectly when declaring a function to return a value with const:

const std::string getValue();
...
foo(getValue());      // would call a function declared as const rvalue reference

Semantically, this case is usually covered by the const lvalue reference overload of a function for read access. A specific implementation of this case is possible but usually makes no sense (the C++ standard library class std::optional<> uses const rvalue references).

2.5 Passing by Value

If you declare a function to take an argument by value, move semantics might also (automatically) be used.

For example:

void foo(std::string str);  // takes the object by value
...
std::string s{"hello"};
...
foo(s);                     // calls foo(), str becomes a copy of s
foo(std::move(s));          // calls foo(), s is moved to str
foo(returnStringByValue()); // calls foo(), return value is moved to str

If the caller signals that it no longer needs the value of the passed argument (by using std::move() or passing a temporary object without a name), the parameter str is initialized with the value moved from the passed argument.

That means that with move semantics, call-by-value can suddenly become cheap if a temporary object is passed or the passed argument is marked with std::move(). Note that just like returning a local object by value, this move can be optimized away. However, if it is not optimized away, the call is guaranteed to be cheap now (if move semantics is cheap).

Note the following difference:

void fooByVal(std::string str);     // takes the object by value
void fooByRRef(std::string&& str);  // takes the object by rvalue reference
...
std::string s1{"hello"}, s2{"hello"};
...
fooByVal(std::move(s1));            // s1 is moved
fooByRRef(std::move(s2));           // s2 might be moved

Here, we compare two functions: one taking the string by value and one taking the string as an rvalue reference. In both cases we pass a string with std::move().

• The function taking the string by value will use move semantics because a new string is created with the value of the passed argument.
• The function taking the string by rvalue reference might use move semantics. Passing the argument does not create a new string. Whether the value of the passed argument is stolen/modified depends on the implementation of the function.

Thus:

• A function declared to support move semantics might not use move semantics.
• A function declared to take an argument by value will use move semantics.

Note again that the effect of move semantics does not guarantee that any optimization happens at all or what the effect of any optimization is. All we know is that the passed object is subsequently in a valid but unspecified state.

2.6 Summary

• Rvalue references are declared with && and no const.
• They can be initialized by temporary objects that do not have a name or non-const objects marked with std::move().
• Rvalue references extend the lifetime of objects returned by value.
• std::move() is a static_cast to the corresponding rvalue reference type. This allows us to pass a named object to an rvalue reference.
• Objects marked with std::move() can also be passed to functions taking the argument by const lvalue reference but not taking a non-const lvalue reference.
• Objects marked with std::move() can also be passed to functions taking the argument by value. In that case, move semantics is used to initialize the parameter, which can make call-by-value pretty cheap.
• const rvalue references are possible but implementing against them usually makes no sense.
• Moved-from objects should be in a valid but unspecified state. The C++ standard library guarantees that for its types. You can still (re)use them providing you do not make any assumptions about their value.

3. Move Semantics in Classes

This chapter shows how classes can benefit from move semantics. It demonstrates how ordinary classes automatically benefit from move semantics and how to explicitly implement move operations in classes.

3.1 Move Semantics in Ordinary Classes

Assume you have quite a simple class with members of types where move semantics can make a difference:

#include <string>
#include <vector>
#include <iostream>
#include <cassert>

class Customer {
 private:
  std::string name;         // name of the customer
  std::vector<int> values;  // some values of the customer
 public:
  Customer(const std::string& n)
   : name{n} {
      assert(!name.empty());
  }

  std::string getName() const {
    return name;
  }

  void addValue(int val) {
    values.push_back(val);
  }

  friend std::ostream& operator<< (std::ostream& strm, const Customer& cust) {
    strm << '[' << cust.name << ": ";
    for (int val : cust.values) {
      strm << val << ' ';
    }
    strm << ']';
    return strm;
  }
};

This class has two (potentially) expensive members, a string for the name and a vector of integral values:

class Customer {
 private:
  std::string name;         // name of the customer
  std::vector<int> values;  // some values of the customer
  ...
};

Both members are expensive to copy

• To copy the name, we have to allocate memory for the characters of the string (unless we have a short name and strings are implemented using the small string optimization (SSO)).
• To copy the values, we have to allocate memory for the elements of the vector.

It would be even more expensive if we had a vector of strings or another pretty expensive element type. For example, a deep copy of a vector of strings would have to allocate memory for both the dynamic array of elements and the memory each element needs.

The good news is that move semantics is usually automatically supported by such a class. Since C++11, the compiler usually generates a move constructor and a move assignment operator (similar to the automatic generation of a copy constructor and a copying assignment operator).

This has the following effect:

• Returning a local Customer by value will use move semantics (if it is not optimized away).
• Passing an unnamed Customer by value will use move semantics (if it is not optimized away).
• Passing a temporary Customer (e.g., returned by another function) by value will use move semantics (if it is not optimized away).
• Passing a Customer object marked with std::move() by value will use move semantics (if it is not optimized away).

For example:

#include "customer.hpp"
#include <iostream>
#include <random>
#include <utility>  // for std::move()

int main()
{
  // create a customer with some initial values:
  Customer c{"Wolfgang Amadeus Mozart" };
  for (int val : {0, 8, 15}) {
    c.addValue(val);
  }
  std::cout << "c: " << c << '\n';    // print value of initialized c

  // insert the customer twice into a collection of customers:
  std::vector<Customer> customers;
  customers.push_back(c);             // copy into the vector
  customers.push_back(std::move(c));  // move into the vector
  std::cout << "c: " << c << '\n';    // print value of moved-from c

  // print all customers in the collection:
  std::cout << "customers:\n";
  for (const Customer& cust : customers) {
    std::cout << "  " << cust << '\n';
  }
}

Here we create and initialize a customer c (to avoid SSO, we use a pretty long name). After the initialization of c, the first output is as follows:

c: [Wolfgang Amadeus Mozart: 0 8 15 ]

We then insert this customer in a vector twice: we copy it once and we move it once:

customers.push_back(c);             // copy into the vector
customers.push_back(std::move(c));  // move into the vector

Afterwards, the next output of the value of c will typically be as follows:

c: [: ]

With the second call of push_back(), both the name and the values were moved away into the second element of the vector. However, do not forget that a moved-from object is in a valid but unspecified state. Thus, the second output could have any value name and values:

• It might still have the same value:

    c: [Wolfgang Amadeus Mozart: 0 8 15 ]
  

• It might have a totally different value:

    c: [value was moved away: 0 ]
  

However, because move semantics is provided to optimize performance and assigning a different value is not necessarily a way to improve performance, it is quite typical that implementations make both the string and the vector empty.

In any case, we can see that move semantics is automatically enabled for the class Customer. For the same reason, it is now guaranteed that the following code is cheap:

Customer createCustomer()
{
  Customer c{...};
  ...
  return c;  // uses move semantics if not optimized away
}

std::vector<Customer> customers;
...
customers.push_back(createCustomer());  // uses move semantics

See basics/customer2.cpp for the complete example.

The important message is that, since C++11, classes automatically benefit from move semantics if they use members that benefit from it. These classes have:

• A move constructor that moves the members if we create a new object from a source where we no longer need the value:

    Customer c1{...}
    ...
    Customer c2{std::move(c1)};  // move members of c1 to members of c2
  

• A move assignment operator that move assigns the members if we assign the value from a source where we no longer need the value.

    Customer c1{...}, c2{...};
    ...
    c2 = std::move(c1);          // move assign members of c1 to members of c2
  

Note that such a class can benefit even further from move semantics by explicitly implementing the following improvements:

• Use move semantics when initializing members
• Use move semantics to make getters both safe and fast

3.1.1 When is Move Semantics Automatically Enabled in Classes?

As just introduced, compilers may automatically generate special move member functions (move constructor and move assignment operator). However, there are constraints. The constraint is that the compiler has to assume that the operations generated do the right thing. The right thing is that we optimize the normal copy behavior: instead of copying members, we move them because the source values are no longer needed.

If classes have changed the usual behavior of copying or assignment, they probably also have to do something different when optimizing these operations. Therefore, the automatic generation of move operations is disabled when at least one of the following special member functions is user-declared:

• Copy constructor
• Copy assignment operator
• Another move operation
• Destructor

Note that I wrote “user-declared.” Any form of an explicit declaration of a copy constructor, copy assignment operator, or destructor disables move semantics. For example, if we implement a destructor that does nothing, we have disabled move semantics:

class Customer {
  ...
  ~Customer() {  // automatic move semantics is disabled
  }
};

Even the following declaration is enough to disable move semantics:

class Customer {
  ...
  ~Customer() = default;  // automatic move semantics is disabled
};

A destructor explicitly requested to have its default behavior is user-declared and therefore disables move semantics. As usual, copy semantics will be used as a fallback in that case.

Therefore: do not implement or declare a destructor if there is not specific need (a rule a surprising number of programmers do not follow).

This also means that by default, a polymorphic base class has disabled move semantics:

class Base {
  ...
  virtual ~Base() {  // automatic move semantics is disabled
  }
};

Note that this means that move semantics is disabled only for members that are declared inside this base class. For members of derived classes, move semantics is still automatically generated (if the derived class does not explicitly declare a special member function). Move Semantics in Class Hierarchies discusses this in detail.

3.1.2 When Generated Move Operations Are Broken

Note that generated move operations might introduce problems even though the generated copy operations work correctly. In particular, you have to be careful in the following situations:

• Members have restrictions on values
  • Values of members have restrictions
  • Values of members depend on each other
• Members with reference semantics are used (pointers, smart pointers, …)
• Objects have no default constructed state

The problem that can occur is that moved-from objects might no longer be valid: invariants might be broken or the destructor of the object might even fail. For example, objects of the Customer class in this chapter might suddenly have an empty name even though we have assertions to avoid that. The chapter about moved-from states will discuss this in detail.

3.2 Implementing Special Copy/Move Member Functions

You can implement the special move member functions yourself. You do this in approximately the same way that a copy constructor and an assignment operator are implemented. The only difference is that the parameter is declared as a non-const rvalue reference and that inside the implementation, you have to specify where to optimize the usual copying with something better.

Let us look at a class that has both special copy and special move member functions implemented to print out when objects are copied and when they are moved:

#include <string>
#include <vector>
#include <iostream>
#include <cassert>

class Customer {
 private:
  std::string name;         // name of the customer
  std::vector<int> values;  // some values of the customer
 public:
  Customer(const std::string& n)
   : name{n} {
      assert(!name.empty());
  }

  std::string getName() const {
    return name;
  }

  void addValue(int val) {
    values.push_back(val);
  }

  friend std::ostream& operator<< (std::ostream& strm, const Customer& cust) {
    strm << '[' << cust.name << ": ";
    for (int val : cust.values) {
      strm << val << ' ';
    }
    strm << ']';
    return strm;
  }

  // copy constructor (copy all members):
  Customer(const Customer& cust) 
   : name{cust.name}, values{cust.values}  {
      std::cout << "COPY " << cust.name << '\n';
  }

  // move constructor (move all members):
  Customer(Customer&& cust)                // noexcept declaration missing
   : name{std::move(cust.name)}, values{std::move(cust.values)} {
      std::cout << "MOVE " << name << '\n';
  }

  // copy assignment (assign all members):
  Customer& operator= (const Customer& cust) {
    std::cout << "COPYASSIGN " << cust.name << '\n';
    name = cust.name;
    values = cust.values;
    return *this;
  }

  // move assignment (move all members):
  Customer& operator= (Customer&& cust) {  // noexcept declaration missing
    std::cout << "MOVEASSIGN " << cust.name << '\n';
    name = std::move(cust.name);
    values = std::move(cust.values);
    return *this;
  }
};

Let us look at the implementations of all special copy/move member functions in detail.

Note that both the move constructor and the move assignment operator should usually have a noexcept declaration when they are manually implemented, which is discussed in the chapter about move semantics and noexcept.

3.2.1 Copy Constructor

The copy constructor is implemented as follows:

class Customer {
 private:
  std::string name;         // name of the customer
  std::vector<int> values;  // some values of the customer
 public:
  ...
  // copy constructor (copy all members):
  Customer(const Customer& cust)
   : name{cust.name}, values{cust.values}  {
      std::cout << "COPY " << cust.name << '\n';
  }
  ...
};

The automatically generated copy constructor does just copy all members. In our implementation, we only add a statement printing that a specific customer is copied.

3.2.2 Move Constructor

The move constructor is implemented as follows:

class Customer {
 private:
  std::string name;         // name of the customer
  std::vector<int> values;  // some values of the customer
 public:
  ...
  // move constructor (move all members):
  Customer(Customer&& cust)                // noexcept declaration missing
   : name{std::move(cust.name)}, values{std::move(cust.values)} {
      std::cout << "MOVE " << name << '\n';
  }
  ...
};

Again, this is what the default generated move constructor would do, extended with the additional print statement.

The key difference to the copy constructor is to declare the parameter as a non-const rvalue reference and then move the members.

Note something very important here: move semantics is not passed through. When we initialize the members with the members of cust, we have to mark them with std::move().⁶ Without this, we would just copy them (the move constructor would have the performance of the copy constructor).

You might wonder why move semantics is not passed through. Did we not declare the parameter cust to accept only objects with move semantics? However, note the semantics here: this function is called when the caller no longer needs the value. Inside the move constructor, we now have the value to deal with and we have to decide where and how long we need it. In particular, we might need the value multiple times and not lose it with its first use.

Therefore, the fact that move semantics is not passed through is a feature, not a bug. If we were to pass move semantics through, we would not be able to use an object that was passed with move semantics twice.

For example:

void insertTwice(std::vector<std::string>& coll, std::string&& str)
{
  coll.push_back(str);             // copy str into coll
  coll.push_back(std::move(str));  // move str into coll
}

If all uses of str implicitly had move semantics, the value of str would be moved away with the first push_back() call.

The important lesson to learn here is that a parameter being declared as an rvalue reference restricts what we can pass to this function but behaves just like any other non-const object of this type. We again have to specify when and where we no longer need the value. See the formal discussion When Rvalues become Lvalues for more details.

One additional note: while the print statement of the copy constructor prints the name of the passed customer:

Customer(const Customer& cust)
 : name{cust.name}, values{cust.values}  {
    std::cout << "COPY " << cust.name << '\n';  // cust.name still there
}

the move constructor cannot use cust.name because in the initialization of the constructor the value might have been moved away. We have to use the member of the new objects instead:

Customer(Customer&& cust)
 : name{std::move(cust.name)}, values{std::move(cust.values)} {
    std::cout << "MOVE " << name << '\n';  // have to use name (cust.name moved away)
}

Note that you should always implement the move constructor with a (conditional) noexcept specification to improve the performance of reallocations of a vector of Customers.

3.2.3 Copy Assignment Operator

The copy assignment operator is implemented as follows:

class Customer {
 private:
  std::string name;         // name of the customer
  std::vector<int> values;  // some values of the customer
 public:
  ...
  // copy assignment (assign all members):
  Customer& operator= (const Customer& cust) {
    std::cout << "COPYASSIGN " << cust.name << '\n';
    name = cust.name;
    values = cust.values;
    return *this;
  }
  ...
};

Like the automatically generated copy assignment operator, we simply assign all members. The only difference is the print statement at the beginning.

When implementing an assignment operator, you can (and maybe should) check for assignments of an object to itself. However, note that the default assignment operator generated does not do that and see the comments about this when discussing self-assignments with the move assignment operator.

You might also want to declare the assignment operator with reference qualifiers.

3.2.4 Move Assignment Operator

The move assignment operator is implemented as follows:

class Customer {
 private:
  std::string name;         // name of the customer
  std::vector<int> values;  // some values of the customer
 public:
  ...
  // move assignment (steal all members):
  Customer& operator= (Customer&& cust) {  // noexcept declaration missing
    std::cout << "MOVEASSIGN " << cust.name << '\n';
    name = std::move(cust.name);
    values = std::move(cust.values);
    return *this;
  }
};

Again, we have to declare the move constructor as a function that takes a non-const rvalue reference. Then in the body, we have to implement how to improve the usual copying by benefiting that we can steal values from the source object.

In this case, we do what the automatically generated move assignment operator would do: we move assign the members in the body instead of copy assigning them. In addition, we add our print statement. Finally, we return the object for further use.

Note that you should usually implement the move assignment operator with a noexcept specification.

You might also want to declare the move assignment operator with reference qualifiers.

3.2.4.1 Dealing with Move Assignments of Objects to Themselves

You might wonder whether you should check for assignments of an object to itself when implementing the move assignment operator. For example, a self move might happen as follows:

Customer c{"GNU's Not Unix"};
c = std::move(c);                     // move assigns c to itself

This looks easy to avoid but we might use references and pointers, and in that case, it is not necessarily that obvious that two objects are the same. Consider the following code as a still quite simple example:

std::vector<Customer> coll;
coll.emplace_back("GNU's Not Unix");  // coll has 1 element
coll[0] = std::move(coll.back());     // move assigns the only element to itself

As written, all types in the C++ standard library receive a valid but unspecified state when objects are moved to themselves. This means that by default, you might lose the values of your members and you might even have a more severe problem if your type does not work properly with members that have arbitrary values. In fact, the resulting state might be a problem in the following situations:

• Some values of a moved-from member are a problem
• The values of members depend on each other

The traditional/naive way to protect against self-assignments is to check whether both operands are identical (have the same address). You can also do this when implementing the move assignment operator:

Customer& operator= (Customer&& cust) {  // noexcept declaration missing
  std::cout << "MOVEASSIGN " << cust.name << '\n';
  if (this != &cust) {              // move assignment to myself?
    name = std::move(cust.name);
    values = std::move(cust.values);
  }
  return *this;
}

Having a check like this is pretty cheap and would have the benefit that the object keeps its value on a self-move-assignment. However, note that in recursive data structures, it can also be a problem if you (move) assign a child object to a parent object. If we delete the old value of the parent (which owns the child) first before we assign the new value, you might then assign a deleted object. In this case, the objects are not identical, which means that comparing their addresses does not help.

In addition, consider the following from style guides:

• In his book Effective C++ Scott Meyers says that self-assignments are usually not a problem when resource management is encapsulated properly by helper classes (but we did not have move semantics at that time). Furthermore, he points out that otherwise, you also have to ensure that the operator is exception-safe.
• The C++ Core Guidelines categorize this problem as a “one-in-a-million problem” that does not appear to be relevant in practice.⁷

It seems that in most cases, you can ignore self-move-assignments, which usually means that in your types, you give the same guarantee as the C++ standard library: after move assigning an object to itself, the object is in a valid but unspecified state.

3.2.5 Using the Special Copy/Move Member Functions

Let us test the class Customer with a small program:

#include "customerimpl.hpp"
#include <iostream>
#include <string>
#include <vector>
#include <algorithm>

int main()
{
  std::vector<Customer> coll;
  for (int i=0; i<12; ++i) {
    coll.push_back(Customer{"TestCustomer " + std::to_string(i-5)}); 
  }

  std::cout << "---- sort():\n";
  std::sort(coll.begin(), coll.end(),
            [] (const Customer& c1, const Customer& c2) {
              return c1.getName() < c2.getName();
            });
}

3.2.5.1 Initialization

The first part is the initialization of the vector with 12 customers:

std::vector<Customer> coll;
for (int i=0; i<12; ++i) {
  coll.push_back(Customer{"TestCustomer " + std::to_string(i-5)});
}

This initialization might have the following output:

MOVE TestCustomer -5
MOVE TestCustomer -4
COPY TestCustomer -5
MOVE TestCustomer -3
COPY TestCustomer -5
COPY TestCustomer -4
MOVE TestCustomer -2
MOVE TestCustomer -1
COPY TestCustomer -5
COPY TestCustomer -4
COPY TestCustomer -3
COPY TestCustomer -2
MOVE TestCustomer 0
MOVE TestCustomer 1
MOVE TestCustomer 2
MOVE TestCustomer 3
COPY TestCustomer -5
COPY TestCustomer -4
COPY TestCustomer -3
COPY TestCustomer -2
COPY TestCustomer -1
COPY TestCustomer 0
COPY TestCustomer 1
COPY TestCustomer 2
MOVE TestCustomer 4
MOVE TestCustomer 5
MOVE TestCustomer 6

Each time we insert a new object, a temporary object is created and moved into the vector. Therefore, for each element, we have a MOVE.

In addition, we have several copies marked with COPY. These copies are caused by the fact that from time to time, a vector reallocates its internal memory (capacity) so that it is big enough for all elements. In this case, the vector grows from having memory for 1 to having memory for 2, 4, 8, and finally 16 elements. Therefore, we have to copy first 1, then 2, then 4, and then 8 elements already in the vector. Calling coll.reserve(20) before the loop would avoid these copies. However, you might wonder why no move is used here. This has to do with the missing noexcept declarations, which we will discuss in the chapter about move semantics and noexcept.

Note that the exact policy of a vector to grow its capacity is implementation-specific. Thus, the output might differ when implementations grow differently (such as growing by 50% each time).

3.2.5.2 Sorting

Next, we sort all elements by name:

std::sort(coll.begin(), coll.end(),
          [] (const Customer& c1, const Customer& c2) {
            return c1.getName() < c2.getName();
          });

This sorting might have the following output:

MOVE TestCustomer -4
MOVEASSIGN TestCustomer -5
MOVEASSIGN TestCustomer -4
MOVE TestCustomer -3
MOVEASSIGN TestCustomer -5
MOVEASSIGN TestCustomer -4
MOVEASSIGN TestCustomer -3
MOVE TestCustomer -2
MOVEASSIGN TestCustomer -5
MOVEASSIGN TestCustomer -4
MOVEASSIGN TestCustomer -3
MOVEASSIGN TestCustomer -2
MOVE TestCustomer -1
MOVEASSIGN TestCustomer -5
MOVEASSIGN TestCustomer -4
MOVEASSIGN TestCustomer -3
MOVEASSIGN TestCustomer -2
MOVEASSIGN TestCustomer -1
MOVE TestCustomer 0
MOVEASSIGN TestCustomer 0
MOVE TestCustomer 1
MOVEASSIGN TestCustomer 1
MOVE TestCustomer 2
MOVEASSIGN TestCustomer 2
MOVE TestCustomer 3
MOVEASSIGN TestCustomer 3
MOVE TestCustomer 4
MOVEASSIGN TestCustomer 4
MOVE TestCustomer 5
MOVEASSIGN TestCustomer 5
MOVE TestCustomer 6
MOVEASSIGN TestCustomer 6

As you can see, the whole sorting is only moving around elements; sometimes to create a new temporary object (MOVE), sometimes to assign a value to a different location (MOVEASSIGN).

Again, the output depends on the exact implementation of sort(), which is implementation-specific.

3.2.5.3 The Number of Copies We Saved

The output of this program again demonstrates the benefit of move semantics. Before move semantics support, we would only have copies when inserting and sorting elements. However, even in this small program that has a container with 12 elements, move semantics converted 44 expensive element copies into cheap moves. For 10,000 customers we would save more than 150,000 copies. And note that each copy of a Customer means up to 2 memory allocations with the corresponding deallocations later on.

Note again:

• The implementation of std::sort() is implementation-specific, meaning that the number of saved copies might differ slightly.
• The only copies performed are caused by the reallocation of the vector for the memory of the elements. They should also become moves, which will be discussed in the chapter about move semantics and noexcept.

3.3 Rules for Special Member Functions

Let us talk about special member functions and in particular, specify exactly when and how the special copy and move member functions are generated.

3.3.1 Special Member Functions

Let us first look briefly at the term special member function, because it is used in different ways. The C++ standard defines the following six operations as special member functions:

• Default constructor
• Copy constructor
• Copy assignment operator
• Move constructor (since C++11)
• Move assignment operator (since C++11)
• Destructor

However, in many cases such as in the rule of five, we talk only about five these operations, because the default constructor is a little different to the other five (or three before C++11) operations. The other five operations are usually not declared and have more complex dependencies. So make sure you always know what is meant by the special member functions (I have tried to avoid this term so far).

The table about the rules of special member functions gives an overview of when special member functions are automatically generated depending on which (other) constructors and special member functions are declared:⁸

There are a few basic rules you can see in this table:

• A default constructor is only declared automatically if no other constructor is user-declared.
• The special copy member functions and the destructor disable move support. The automatic generation of special move member functions is disabled (unless the moving operations are also declared). However, still a request to move an object usually works because the copy member functions are used as a fallback (unless the special move member functions are explicitly deleted).
• The special move member functions disable the normal copying and assignment. The copying and other moving special member functions are deleted so that you can only move (assign) but not copy (assign) an object (unless the other operations are also declared).

Let us look at some details.

3.3.2 By Default, We Have Copying and Moving

As written, by default, both copying and moving special member functions are generated for a class.

Assume the following declaration of a class Person:

class Person {
    ...
  public:
    ...
    // NO copy constructor/assignment declared

    // NO move constructor/assignment declared

    // NO destructor declared
};

In this case, a Person can be both copied and moved:

std::vector<Person> coll;

Person p{"Tina", "Fox"};
coll.push_back(p);                      // OK, copies p
coll.push_back(std::move(p));           // OK, moves p

3.3.3 Declared Copying Disables Moving (Fallback Enabled)

When declaring a copying special member function (or the destructor), we have the automatic generation of the moving special member functions disabled:

Assume the following declaration of a class Person:

class Person {
    ...
  public:
    ...
    // copy constructor/assignment declared:
    Person(const Person&) = default;
    Person& operator=(const Person&) = default;

    // NO move constructor/assignment declared
};

Because the fallback mechanism works, copying and moving a Person compiles but the move is performed as a copy:

std::vector<Person> coll;

Person p{"Tina", "Fox"};
coll.push_back(p);                      // OK, copies p
coll.push_back(std::move(p));           // OK, copies p

Thus, declaring a special member function with =default is not the same as not declaring it at all. The copy constructor and copy assignment are user-declared, which disables move construction and move assignment so that moves fall back to copies. A declared destructor has the same effect.

You might wonder why a declared destructor disables move semantics. The chapter about moved-from states discusses a concrete example of a a class with a destructor that causes generated move semantics not to work properly.

3.3.4 Declared Moving Disables Copying

If you have user-declared move semantics, you have disabled copy semantics. The copying special member functions are deleted.

In other words, if the move constructor or the move assignment operator is explicitly declared (implemented, generated with =default, or disabled with =delete), you have disabled to call the copy constructor and the copy assignment operator by declaring them with =delete.

Assume the following declaration of a class Person:

class Person {
    ...
  public:
    ...
    // NO copy constructor declared

    // move constructor/assignment declared:
    Person(Person&&) = default;
    Person& operator=(Person&&) = default;
};

In this case, we have a move-only type. A Person can be moved but not copied:

std::vector<Person> coll;

Person p{"Tina", "Fox"};
coll.push_back(p);                      // ERROR: copying disabled
coll.push_back(std::move(p));           // OK, moves p

coll.push_back(Person{"Ben", "Cook"});  // OK, moves temporary person into coll

Again, declaring a special member function with =default is not the same as not declaring it at all. However, this time, the consequences for the caller are more severe: the attempt to copy an object will no longer compile.

A class supporting move operations but not copy operations can make sense. You can use such a move-only type to pass around ownership or handles of resources without sharing or copying them. In the C++ standard library there are a couple of move-only types (e.g., I/O stream classes, thread classes, and std::unique_ptr<>). See the chapter about move-only types for details.

3.3.5 Deleting Moving Makes No Sense

For the same reason, if you declare the move constructor as deleted, you cannot move (you have disabled this operation; any fallback is not used) and cannot copy (because a declared move constructor disables copy operations):

class Person {
  public:
    ...
    // NO copy constructor declared

    // move constructor/assignment declared as deleted:
    Person(Person&&) = delete;
    Person& operator=(Person&&) = delete;
    ...
};

Person p{"Tina", "Fox"};
coll.push_back(p);                      // ERROR: copying disabled
coll.push_back(std::move(p));           // ERROR: moving disabled

You get the same effect by declaring copying special member functions as deleted and that is probably less confusing for other programmers.

Deleting the move operations and enabling the copy operations really makes no sense:

class Person {
  public:
    ...
    // copy constructor explicitly declared:
    Person(const Person& p) = default;
    Person& operator=(const Person&) = default;

    // move constructor/assignment declared as deleted:
    Person(Person&&) = delete;
    Person& operator=(Person&&) = delete;
    ...
};

Person p{"Tina", "Fox"};
coll.push_back(p);                      // OK: copying enabled
coll.push_back(std::move(p));           // ERROR: moving disabled

In this case, =delete disables the fallback mechanism (and is therefore also not the same as not declaring it at all). The compiler finds the declaration and reports the call as an error.

A type that supports copying but fails when moving is called does not make any sense. For the user of such a class, copying would sometimes work, sometimes not. As a guideline: never =delete the special move member functions.⁹ If you want to disable both copying and moving, deleting the copying special member functions is enough.

3.3.6 Disabling Move Semantics with Enabled Copy Semantics

Based on what we have just discussed, we now know how to disable move semantics when copying still makes sense. Declaring the special move member functions as deleted is usually not the right way to do it because it disables the fallback mechanism.

The right way to disable move semantics while providing copy semantics is to declare one of the other special member functions (copy constructor, assignment operator, or destructor). I recommend that you default the copy constructor and the assignment operator (declaring one of them would be enough but might cause unnecessary confusion):

class Customer {
  ...
 public:
  ...
  Customer(const Customer&) = default;             // disable move semantics
  Customer& operator=(const Customer&) = default;  // disable move semantics
};

Because no generated special move member functions are found, a nameless temporary customer or even a customer marked with std::move() is now copied:

std::vector<Customer> customers;
...
customers.push_back(createCustomer());         // OK, falls back to copying
customers.push_back(std::move(customers[0]));  // OK, falls back to copying

However, it is usually better to implement the special move member functions to fix any problem a default generated move operation has. The chapter about moved-from states will discuss examples from practice.

Note that only declaring the special copy member functions breaks the common “rule of five,” which we will discuss later in detail. You have to declare the special copy member functions but cannot also declare the special move member functions (both deleting and defaulting would not work, implementing them makes the class unnecessarily complicated). Therefore, if you explicitly declare a copying special member function just to disable move semantics, add a big comment to ensure that this declaration is neither removed nor extended by a declaration of the special move member functions.

3.3.7 Moving for Members with Disabled Move Semantics

Note that if move semantics is unavailable or has been deleted for a type, this has no influence on the generation of move semantics for classes that have members of this type. The generated default move constructor and assignment operator decide member by member whether to copy or to move it. If a move is not possible (even if the move operation is deleted), a copy is generated (if possible).

For example, assume the following class:

class Customer {
  ...
 public:
  ...
  Customer(const Customer&) = default;             // copying calls enabled
  Customer& operator=(const Customer&) = default;  // copying calls enabled
  Customer(Customer&&) = delete;                   // moving calls disabled
  Customer& operator=(Customer&&) = delete;        // moving calls disabled
};

If this class is used by a member in the other class:

class Invoice {
  std::string id;
  Customer cust;
 public:
  ...  // no special member functions
};

the generated move constructor will move the id string but copy the customer cust:

Invoice i;
Invoice i1{std::move(i)};   // OK, moves id, copies cust

3.3.8 Exact Rules for Generated Special Member Functions

Now we can summarize the new rules for special member functions (when they are generated and how they behave).

As an example, assume we have the following derived class:

class MyClass : public Base
{
 private:
  MyType value;
  ...
};

The one thing missing here is the noexcept specification, which we introduce later in the chapter about noexcept. However, we will mention the corresponding guarantees here.

3.3.8.1 Copy Constructor

The copy constructor is automatically generated when all of the following apply:¹⁰

• No move constructor is user-declared
• No move assignment operator is user-declared

If generated (implicitly or with =default), the copy constructor has the following behavior:¹¹

MyClass(const MyClass& obj) noexcept-specifier
 : Base(obj), value(obj.value) {
}

The generated copy constructor first passes the source object, to the best matching copy constructor of the base class(es). (remember that copy constructors are always called on a top-down basis). It prefers the copy constructor with the same declaration (usually declared const&), but if that is not available it might call the next best matching constructor (e.g., a copy constructor template). Afterwards, it copies all members of its class (again using the best match).

The generated copy constructor is declared as noexcept if all copy operations (the copy constructors of all base classes and the copy constructors of all members) give this guarantee.

3.3.8.2 Move Constructor

The move constructor is automatically generated when all of the following apply:

• No copy constructor is user-declared
• No copy assignment operator is user-declared
• No move assignment operator is user-declared
• No destructor is user-declared

If generated (implicitly or with =default), the move constructor has the following behavior:

MyClass(MyClass&& obj) noexcept-specifier
 : Base(std::move(obj)), value(std::move(obj.value)) {
}

The generated move constructor first passes the source object, marked with std::move() to pass through its move semantics, to the best matching move constructor of the base class(es). The best matching move constructor usually is the one with the same declaration (declared with &&). However, if that is not available it might call the next best matching constructor (e.g., a move constructor template or even a copy constructor). Afterwards, it moves all members of its class (again using the best match).

The generated move constructor is declared as noexcept if all called move/copy operations (the copy or move constructors of all base classes and the copy or move constructors of all members) give this guarantee.

3.3.8.3 Copy Assignment Operator

The copy assignment operator is automatically generated when all of the following apply:¹²

• No move constructor is user-declared
• No move assignment operator is user-declared

If generated (implicitly or with =default), the copy assignment operator approximately has the following behavior:¹³

MyClass& operator= (const MyClass& obj) noexcept-specifier {
  Base::operator=(obj);    // - perform assignments for base class members
  value = obj.value;       // - assign new members
  return *this;
}

The generated copy assignment operator first calls the best matching assignment operator of the base class(es) for the passed source object (remember that assignment operators in contrast to copy constructors are not called on a top-down basis; they call the base class assignment operator(s) in the implementation). Afterwards it assigns all members of its class (again using the best match).

Note that the generated assignment operator does not check for assignments of objects to themselves. If this is critical, you have to implement the operator yourself.

In addition, the generated copy assignment operator is declared as noexcept if all assignment operations (the assignment of the base class members and the assignment of the new members) give this guarantee.

3.3.8.4 Move Assignment Operator

The move assignment operator is automatically generated when all of the following apply:

• No copy constructor is user-declared
• No move constructor is user-declared
• No copy assignment operator is user-declared
• No destructor is user-declared

If generated (implicitly or with =default), the move assignment operator approximately has the following behavior:

MyClass& operator= (MyClass&& obj) noexcept-specifier {
  Base::operator=(std::move(obj));  // - perform move assignments for base class members
  value = std::move(obj.value);     // - move assign new members
  return *this;
}

The generated move assignment operator first calls the best matching move assignment operator of the base class(es) for the passed source object, marked with std::move() to pass through its move semantics. Afterwards it move assigns all members of its class (again using the best match).

You might wonder why we still use members of the source object obj after the object was marked with std::move():

Base::operator=(std::move(obj));  // - perform move assignments for base class members

However, in this case we mark the object for the specific context of a base class, which cannot see the members introduced in this class. Therefore, the derived members have a valid but unspecified state but we can still use the values of the new members.

The generated assignment operator also does not check for assignments of objects to themselves. Thus, in its default behavior, the operator will move assign each member to itself, which usually means that members receive a valid but unspecified value. If this is critical, you have to implement the operator yourself.

In addition, the generated move assignment operator is declared as noexcept if all called assignment operations (the assignments for base class members and the assignments for new members) give this guarantee.

3.3.8.5 Other Special Member Functions

Other special member functions do not play such an important role for move semantics:

• Destructors are nothing special with move semantics except that their declaration disables the automatic generation of move operations.
• The default constructor (the “not-so-special” special member function) is still automatically generated if no other constructor is declared. That is, the declaration of a move constructor disables the generation of a default constructor.

However, note that these special member functions play a role when talking about moved-from states. The state of the default constructor is often the “natural” state of a moved-from object and a moved-from object always should be destructible.

3.4 The Rule of Five or Three

Whether and which special member functions are automatically generated depends on a combination of several of the rules just described. Many programmers do not know all these rules. Therefore, even before C++11, the usual guideline is to provide either none or all of the special member functions for copying, assignment, and destruction.

• Before C++11, this guideline was called the Rule of Three: The guideline was to either declare all three (copy constructor, assignment operator, and destructor) or none of them.
• Since C++11, the rule has become the Rule of Five, which is usually formulated as:¹⁴ The guideline is to either declare all five (copy constructor, move constructor, copy assignment operator, move assignment operator, and destructor) or none of them.

Here, declaring means:

• Either to implement ({…})
• Or to declare as defaulted (=default)
• Or to declare as deleted (=delete)

That is, when one of these special member functions is either implemented or defaulted or deleted, you should implement or default or delete all four other special member functions.

However, you should be careful with this rule. I recommend that you take it more as a guideline to carefully think about all of these five special member functions when one of them is user-declared.

As we saw, to enable copy semantics only you should =default the copying special member functions without declaring the special move member functions (deleting and defaulting the special move member functions would not work, implementing them makes the class unnecessarily complicated). This option is recommended in particular if the generated move semantics creates invalid states, as we discuss in the section about invalid moved-from states.

When applying this rule of five, it also turned out that sometimes, programmers use it to add declarations for the new move operations without understanding what this means. Programmers were just declaring move operations with =default because copy operations were implemented and they wanted to follow the rule of five.

Therefore, I usually teach the Rule of Five or Three:

• If you declare the copy constructor, move constructor, copy assignment operator, move assignment operator, or destructor, think very carefully about how to deal with the other special member functions.
• If you do not understand move semantics, think only about the copy constructor, copy assignment operator, and destructor if you are declaring one of them. If in doubt, disable move semantics by declaring the copying special member functions with =default.

3.5 Summary

• Move semantics is not passed through.
• For every class, the move constructor and move assignment operator are automatically generated (unless there is no way to do so).
• User-declaring a copy constructor, copy assignment operator, or destructor disables the automatic support of move semantics in a class. This does not impact the support in derived classes.
• User-declaring a move constructor or move assignment operator disables the automatic support of copy semantics in a class. You get move-only types (unless these special move member functions are deleted).
• Never =delete a special move member function.
• Do not declare a destructor if there is no specific need. There is no general need in classes derived from a polymorphic base class.

4. How to Benefit From Move Semantics

Most of the time, programmers benefit from move semantics automatically. However, even as an ordinary application programmer, you can benefit from move semantics even more when programming slightly differently.

This chapter discusses how to benefit from move semantics in ordinary application code, classes, and class hierarchies beyond the automatic generation of special move member functions. The chapter also introduces corresponding new guidelines.

Note that even several years after introducing move semantics these recommendations are not widely known in the community. In fact, one reason for me to write this book was to make them state of the art for modern C++ programming.

4.1 Avoid Objects with Names

As we have seen, move semantics allows us to optimize using a value from a source that no longer needs that value. If compilers automatically detect that a value is used from an object that is at the end of its lifetime, they will automatically switch to move semantics. This is the case when:

• We pass a temporary object that will automatically be destroyed after the statement.
• We return a local object by value.

In addition, we can force move semantics by marking an object with std::move().

Because it is easier to just to let compilers do the work, a first consequence of move semantics is the following advice: avoid objects with names.

Instead of

MyType x{42, "hello"};
foo(x);    // x not used afterwards

it would be better to program:

foo(MyType{42,"hello"});

to automatically enable move semantics.

Of course, the advice to avoid objects with names might conflict with other important style guidelines such as readability and maintainability of source code. Instead of having a complex statement, it might be better to use multiple statements. In that case, you should use std::move() if you no longer need an object (and know that copying the object might take significant time):

foo(std::move(x));

4.1.1 When You Cannot Avoid Using Names

There are cases where you cannot avoid using std::move() because you have to give objects names. The most obvious typical examples are:

• You have to use an object multiple times. For example, you might get a value to process it twice in a function or loop:

    std::string str{getData()};
    ...
    coll1.push_back(str);                // copy (still need the value of str)
    coll2.push_back(std::move(str));     // move (no longer need the value of str)
  

  The same applies when inserting the value in the same collection twice or calling two different functions storing the value somewhere.

• You have to deal with a parameter. The most common example of this is the following loop:

    // read and store line by line from myStream in coll
    std::string line;
    while (std::getline(myStream, line)) {
      coll.push_back(std::move(line));   // move (no longer need the value of line)
    }
  

4.2 Avoid Unnecessary std::move()

As we saw, returning a local object by value automatically uses move semantics if supported. However, just to be safe, programmers might try to force this with an explicit std::move():

std::string foo()
{
  std::string s;
  ...
  return std::move(s);  // BAD: don't do this
}

Remember that std::move() is just a static_cast to an rvalue reference. Therefore, std::move(s) is an expression that yields the type std::string&&. However, this no longer matches the return type and therefore disables the return value optimization, which usually allows the returned object to be used as a return value. For types where move semantics is not implemented, this might even force the copying of the return value instead of just using the returned object as the return value.

Therefore, if you return local objects by value, do not use std::move():

std::string foo()
{
  std::string s;
  ...
  return s;             // best performance (return value optimization or move)
}

Using std::move() when you already have a temporary object is at least redundant. For a function createString() that returns an object by value, you should just use the return value:

std::string s{createString()};              // OK

instead of marking it with std::move() again:

std::string s{std::move(createString())};   // BAD: don't do this

Compilers might (have options to) warn about any counterproductive or unnecessary use of std::move(). For example, gcc has the options -Wpessimizing-move (enabled with -Wall) and -Wredundant-move (enabled with -Wextra).

There are applications, though, where a std::move() in a return statement might be appropriate. One example is moving out the value of a member. Another example is returning a parameter with move semantics.

4.3 Initialize Members with Move Semantics

A surprising consequence is that you can benefit from move semantics even in trivial classes with members of types that benefit from move semantics (such as string members or containers).

Let us look at this with a simple example.

4.3.1 Initialize Members the Classical Way

Consider a class with two string members, which we can initialize in the constructor. Such a class will typically be implemented like this:

#include <string>

class Person {
 private:
  std::string first;  // first name
  std::string last;   // last name
 public:
  Person(const std::string& f, const std::string& l)
   : first{f}, last{l} {
  }
  //...
};

Now let us look at what happens when we initialize an object of this class with two string literals:

Person p{"Ben", "Cook"};

The compiler finds out that the provided constructor can perform the initialization. However, the types of the parameters do not fit. Therefore, the compiler generates code to first create two temporary std::strings, which are initialized by the values of the two string literals, and binds the parameters f and l to them:

In general (if the small string optimization (SSO) is not available or the strings are too long), this means that code is generated that allocates memory for the value of each std::string.

However, the temporary strings created are not used directly as members first or last. Instead, they are used to initialize these members. Unfortunately, move semantics is not used here for two reasons:

• The parameters f and l, are objects with names that exist for a longer period than the initialization of the members (you can still use them in the body of the constructor).
• The parameters are declared to be const, which disables move semantics even if we use std::move().

As a consequence, the copy constructor for strings is called on each member initialization, again allocating memory for the values:

At the end of the constructor, the temporary strings are destroyed:

This means that we have four memory allocations although only two are necessary. Using move semantics we can do better.

4.3.1.1 Using non-const Lvalue References?

You may wonder why we cannot simply use non-const lvalue references here:

class Person {
  ...
  Person(std::string& f, std::string& l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  ...
};

However, passing const std::strings and temporary objects (e.g., created from a type conversion) would not compile:

Person p{"Ben", "Cook"};  // ERROR: cannot bind a non-const lvalue reference to a temporary

In general, a non-const lvalue reference does not bind to a temporary object. Therefore, this constructor could not bind f and l to temporary strings created from the passed string literals.

4.3.2 Initialize Members via Moved Parameters Passed by Value

With move semantics, there is now a simple alternative way for constructors to initialize members: the constructor takes each argument by value and moves it into the member:

#include <string>

class Person {
 private:
  std::string first;  // first name
  std::string last;   // last name
 public:
  Person(std::string f, std::string l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  //...
};

This single constructor takes all possible arguments and ensures that we have only one allocation for each argument.

For example, if we pass two string literals:

Person p{"Ben", "Cook"};

we first use them to initialize the parameters f and l:

By using std::move(), we move the values of the parameters to the members. First, the member first steals the value from f:

Then, the member last steals the value from l:

Again, at the end of the constructor, the temporary strings are destroyed. This time it takes less time because the destructors of the strings no longer have to free allocated memory:

This way to initialize the members also works fine if we pass std::strings:

• If we pass two existing strings without marking them with std::move(), we copy the names to the parameters and move them to the members:

    std::string name1{"Jane"}, name2{"White"};
    ...
    Person p{name1, name2};   // OK, copy names into parameters and move them to the members
  

• If we pass two strings where the value is no longer needed, we do not need any allocation at all:

    std::string firstname{"Jane"};
    ...
    Person p{std::move(firstname),     // OK, move names via parameters to members
             getLastnameAsString()};
  

  In this case we move the passed strings twice: once to initialize the parameters f and l and once to move the values of f and l to the members.

Provided a move is cheap, with this implementation of only one constructor any initialization is possible and cheap.

4.3.3 Initialize Members via Rvalue References

There are even more ways to initialize the members of a Person, using multiple constructors.

4.3.3.1 Using Rvalue References

To support move semantics, we have already learned that we can declare a parameter as a non-const rvalue reference. This allows the parameter to steal the value from a passed temporary object or an object marked with std::move().

Consider we declare the constructor as follows:

class Person {
  ...
  Person(std::string&& f, std::string&& l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  ...
};

This initialization would also work for our passed string literals:

Person p{"Ben", "Cook"};

Again, because the constructor needs strings, we would create two temporary strings to which f and l bind:

And because we have non-const references, we can modify them. In this case, we mark them with std::move() so that the initialization of the members can steal the values.

First, the member first steals the value from f:

Then, the member last steals the value from l:

Again, at the end of the constructor, the temporary strings are destroyed without the need to free allocated memory:

However, this constructor does not work in all cases.

4.3.3.2 Overloading for Rvalue and Lvalue References

While functions that take rvalue references work fine when we pass temporary objects to them (here, we pass temporary std::strings created from string literals), they also have restrictions: we cannot pass named objects that still need the value afterwards. Therefore, is we have only a constructor that takes rvalue references, we cannot pass an existing string:

class Person {
  ...
  Person(std::string&& f, std::string&& l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  ...
};

Person p1{"Ben", "Cook"};  // OK

std::string name1{"Jane"}, name2{"White"};
...
Person p2{name1, name2};   // ERROR: can't pass a named object to an rvalue reference

For the case of p2 we would need a traditional constructor, which is declared with a const lvalue reference. However, we might also pass a string literal and an existing string. Therefore, in total, we need four constructors for all possible combinations:

class Person {
  ...
  Person(const std::string& f, const std::string& l)
   : first{f}, last{l} {
  }
  Person(const std::string& f, std::string&& l)
   : first{f}, last{std::move(l)} {
  }
  Person(std::string&& f, const std::string& l)
   : first{std::move(f)}, last{l} {
  }
  Person(std::string&& f, std::string&& l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  ...
};

That way, we can pass both string literals and existing strings in any combination and always have only one allocation per member.

4.3.3.3 Overloading Even for String Literals

To improve the performance even more, we might even have specific implementations that take string literals as ordinary pointers. That way, we could avoid even some moves. However, implementing all constructors becomes a bit tedious:

#include <string>

class Person {
 private:
  std::string first;  // first name
  std::string last;   // last name
 public:
  Person(const std::string& f, const std::string& l)
   : first{f}, last{l} {
  }
  Person(const std::string& f, std::string&& l)
   : first{f}, last{std::move(l)} {
  }
  Person(std::string&& f, const std::string& l)
   : first{std::move(f)}, last{l} {
  }
  Person(std::string&& f, std::string&& l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  Person(const char* f, const char* l)
   : first{f}, last{l} {
  }
  Person(const char* f, const std::string& l)
   : first{f}, last{l} {
  }
  Person(const char* f, std::string&& l)
   : first{f}, last{std::move(l)} {
  }
  Person(const std::string& f, const char* l)
   : first{f}, last{l} {
  }
  Person(std::string&& f, const char* l)
   : first{std::move(f)}, last{l} {
  }
  //...
};

The benefit of this solution is that we reduce the number of moves. If we pass a string literal, we initialize the members directly with the passed pointer instead of creating a std::string and moving its value to the member.

4.3.4 Compare the Different Approaches

With the introduction of new ways of initializing members, the obvious question is, which technique should we use when? And also: which technique should we teach?

In general, there should be a good reason not to use the simple approach with const&. This reason is usually performance. Therefore, let us measure how long it takes to initialize Persons with three kinds of arguments: passing string literals, passing existing strings, and passing strings marked with std::move():

std::string fname = "a first name";
std::string lname = "a last name";

// measure how long this takes:
Person p1{"a firstname", "a lastname"};
Person p2{fname, lname};
Person p3{std::move(fname), std::move(lname)};

However, to avoid the small string optimization (SSO), which would mean that the strings do not allocate any memory at all, we should use strings of significant length. So, here is a full function to measure the different approaches:

#include <chrono>

// measure num initializations of whatever is currently defined as Person:
std::chrono::nanoseconds measure(int num)
{
  std::chrono::nanoseconds totalDur{0};
  for (int i = 0; i < num; ++i) {
    std::string fname = "a firstname a bit too long for SSO";
    std::string lname = "a lastname a bit too long for SSO";

    // measure how long it takes to create 3 Persons in different ways:
    auto t0 = std::chrono::steady_clock::now();
      Person p1{"a firstname too long for SSO", "a lastname too long for SSO"};
      Person p2{fname, lname};
      Person p3{std::move(fname), std::move(lname)};
    auto t1 = std::chrono::steady_clock::now();
    totalDur += t1 - t0;
  }
  return totalDur;
}

The function measure() returns the duration of num iterations performing the three initializations above with strings of a significant length.

Now we combine the different definitions of the class Person above with the measuring function in programs with main() functions that call the measurements and print the resulting durations. For example:

#include "initclassic.hpp"
#include "initmeasure.hpp"
#include <iostream>
#include <cstdlib>   // for std::atoi()

int main(int argc, const char** argv)
{
  int num = 1000;  // num iterations to measure
  if (argc > 1) {
    num = std::atoi(argv[1]);
  }

  // a few iterations to avoid measuring initial behavior:
  measure(5);

  // measure (in integral nano- and floating-point milliseconds):
  std::chrono::nanoseconds nsDur{measure(num)};
  std::chrono::duration<double, std::milli> msDur{nsDur};

  // print result:
  std::cout << num << " iterations take:  "
            << msDur.count() << "ms\n";
  std::cout << "3 inits take on average:  "
            << nsDur.count() / num << "ns\n";
}

The other two programs, basics/initallperf.cpp and basics/initmoveperf.cpp, just use different header files for the other declarations of the class Person.

The effect of running this code on three different platforms with three different compilers with significant optimization activated are as follows:

• In general, the initializations using the classic lvalue references (const &) take significantly more time than the other initializations. I have seen factors of up to 2.
• There is no big difference between implementing all nine constructors and just the constructor taking the argument by value and move. Sometimes one approach was a little faster, sometimes the other; often there was no significant difference.

If we benefit from the small string optimization (SSO), by using quite short strings, which means that we do not allocate any memory at all (and move semantics should be no significant help), the numbers are quite close. Nevertheless, you can still measure a slight drawback using the traditional constructor that takes a const lvalue reference. However, this definitely requires that good optimization is activated.

Besides trying the different test programs, you can use basics/initperf.cpp as one combined program that performs all these different measurements on your favorite platform.

However, you might have very expensive members that do not benefit from move semantics (such as an array of 10000 double values):

class Person {
 private:
  std::string name;
  std::array<double, 10000> values;  // move can't optimize here
 public:
  ...
};

In such a situation, we get a problem with the approach of taking an initial argument of 10000 doubles by value and move. We have to copy the argument twice, which takes almost twice as much time. See basics/initbigperf.cpp for a complete example program to measure this.

4.3.5 Summary for Member Initialization

As a summary, to initialize members for which move semantics makes a significant difference (strings, containers, or classes/arrays with such members), you should use move semantics on of the following alternatives:

• switch from taking the parameter by lvalue reference to taking it by value and move it into the member
• Overload the constructors for move semantics

The first option allows us to have only one constructor so that the code is easier to maintain. However, this does result in more move operations than necessary. Therefore, if move operations might take significant time, you are better to use multiple overloads.

For example, if we have a class with a string and a vector of values, taking by value and move is usually the right approach:

class Person {
 private:
  std::string name;
  std::vector<std::string> values;
 public:
  Person(std::string n, std::vector<std::string> v)
   : name{std::move(n)}, values{std::move(v)} {
  }
  ...
};

However, if we have a std::array member, it is better to overload because moving a std::array still takes significant time even if the members are moved:

class Person {
 private:
  std::string name;
  std::array<std::string, 1000> values;
 public:
  Person(std::string n, const std::array<std::string, 1000>& v)
   : name{std::move(n)}, values{v} {
  }
  Person(std::string n, std::array<std::string, 1000>&& v)
   : name{std::move(n)}, values{std::move(v)} {
  }
  ...
};

4.3.6 Should We Now Always Pass by Value and Move?

The discussion above leads to the question of whether we should now always take arguments by value and move them to set an internal value or member. The answer is no.

The special case discussed here is that we create and initialize a new value. In this case, this strategy pays off. If we already have a value, which we update or modify, using this approach would be counterproductive.

A simple example would be setters. Consider the following implementation of the class Person:

class Person {
 private:
  std::string first;  // first name
  std::string last;   // last name
 public:
  Person(std::string f, std::string l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  ...
  void setFirstname(std::string s) {         // take by value
    first = std::move(s);                    // and move
  }
  ...
};

Assume we use the class as follows:

Person p{"Ben", "Cook"};
std::string name1{"Ann"};
std::string name2{"Constantin Alexander"};

p.setFirstname(name1);
p.setFirstname(name2);
p.setFirstname(name1);
p.setFirstname(name2);

Each time we set a new firstname we create a new temporary parameter s which allocates its own memory, which is then moved to the value of the member. Thus, we have four allocations (provided we do not have SSO).

Now consider that we implement the setter in the traditional way taking a const lvalue reference:

class Person {
 private:
  std::string first;  // first name
  std::string last;   // last name
 public:
  Person(std::string f, std::string l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  ...
  void setFirstname(const std::string& s) {  // take by reference
    first = s;                               // and assign
  }
  ...
};

Binding s to the passed argument will not create a new string. Furthermore, the assignment operator will only allocate new memory if the new length exceeds the current amount of memory allocated for the value. This means that, because we already have a value, the approach of taking the argument by value and move might be counterproductive.

You might wonder whether to overload the setter so that we can benefit from move semantics if the new length exceeds the existing length:

class Person {
 private:
  std::string first;  // first name
  std::string last;   // last name
 public:
  Person(std::string f, std::string l)
   : first{std::move(f)}, last{std::move(l)} {
  }
  ...
  void setFirstname(const std::string& s) {  // take by lvalue reference
    first = s;                               // and assign
  }
  void setFirstname(std::string&& s) {       // take by rvalue reference
    first = std::move(s);                    // and move assign
  }
  ...
};

However, even this approach might be counterproductive, because a move assignment might shrink the capacity of first:

Person p{"Ben", "Cook"};

p.setFirstname("Constantin Alexander");  // would allocate enough memory
p.setFirstname("Ann");                   // would reduce capacity
p.setFirstname("Constantin Alexander");  // would have to allocate again

Even with move semantics, the best approach for setting existing values is to take the new values by const lvalue reference and assign without using std::move().

Taking a parameter by value and moving it to where the new value is needed is only useful when we store the passed value somewhere as a new value (so that we need new memory for it anyway). When modifying an existing value, this policy might be counterproductive.

However, initializing members is not the only application of “take by value and move.” A (member) function adding a new value to a container would be another application:

class Person {
 private:
  std::string name;
  std::vector<std::string> values;
 public:
  Person(std::string n, std::vector<std::string> v)
   : first{std::move(n)}, values{std::move(v)} {
  }
  ...
  // better pass by value and move to create a new element:
  void addValue(std::string s) {         // take by value
    values.push_back(std::move(s));      // and move into the collection
  }
  ...
};

4.4 Move Semantics in Class Hierarchies

As we have seen, any declaration of a copy constructor, copy assignment, or destructor disables the automatic support for move semantics. This also applies to polymorphic base classes. However, there are a few additional aspects to consider.

4.4.1 Implementing a Polymorphic Base Class

A polymorphic base class usually introduces the virtual member functions you can call for all objects of derived classes. For example:

class GeoObj {
 public:
  virtual void draw() const = 0;    // pure virtual function (introducing the API)
  ...
  virtual ~GeoObj() = default;      // let delete call the right destructor
  ...   // other special member functions due to the problem of slicing
};

In this base class, move semantics is disabled, which means that if we move a geometric object the members declared here in the base class have no automatic support for move semantics. This also applies if we have a protected copy constructor and a deleted assignment operator, which you should usually have in a polymorphic base class to avoid the problem of slicing.

As long as the base class does not introduce members, not supporting move semantics has no effect. However, if we have an expensive member in this base class, you have disabled move support for it. For example:

class GeoObj {
 protected:
  std::string name;                 // name of the geometric object
 public:
  ...
  virtual void draw() const = 0;    // pure virtual function (introducing the API)
  ...
  virtual ~GeoObj() = default;      // disables move semantics for name
  ...   // other special member functions due to the problem of slicing
};

To enable move semantics again, you can explicitly declare the move operations as defaulted. However, as we have just learned, this disables the copying special member functions. Therefore, if you want to have these functions, you have to provide them explicitly.

4.4.1.1 Dealing with Slicing

However, there is the problem of slicing. Consider the following code using a reference of the base class GeoObj for objects of the derived class Circle:

Circle c1{...}, c2{...};

GeoObj& geoRef{c1};
geoRef = c2;        // OOPS: uses GeoObj::operator=() and assigns no Circle members

Because we call the assignment operator for a GeoObj and the operator is not virtual, the compiler calls GeoObj::operator=(), which does not deal with any member of any derived class. Even declaring the assignment operator with virtual would not help, because an operator of the derived class does not override the assignment operator of the base class (the parameter types for the second operand differ).

To avoid this problem, you should disable the use of the assignment operator in polymorphic class hierarchies. Furthermore, if the class is not abstract, you should also avoid having public copy constructors to disable implicit type conversions to the base class. Therefore, a polymorphic base class with move semantics (and members) should be declared as follows:

class GeoObj {
 protected:
  std::string name;                 // name of the geometric object

  GeoObj(std::string n)
   : name{std::move(n)} {
  }
 public:
  virtual void draw() const = 0;    // pure virtual function (introducing the API)
  ...
  virtual ~GeoObj() = default;      // would disable move semantics for name
 protected:
  // enable copy and move semantics (callable only for derived classes):
  GeoObj(const GeoObj&) = default;
  GeoObj(GeoObj&&) = default;
  // disable assignment operator (due to the problem of slicing):
  GeoObj& operator= (GeoObj&&) = delete;
  GeoObj& operator= (const GeoObj&) = delete;
};

See poly/geoobj.hpp for the complete header file.

4.4.2 Implementing a Polymorphic Derived Class

A polymorphic derived class might look as follows (see poly/polygon.hpp for the complete header file):¹⁵

class Polygon : public GeoObj {
 protected:
  std::vector<Coord> points;
 public:
  Polygon(std::string s, std::initializer_list<Coord> = {});  // constructor
  virtual void draw() const override;   // implementation of draw()
};

Usually, in a polymorphic derived classes there is no need to declare a special member function. Especially, there is no need to declare a virtual destructor again (unless you have to implement it). Declaring a destructor again (whether or not it is virtual) would disable automatic support of move semantics for the members of the derived class (here, for the vector points):

class Polygon : public GeoObj {
 protected:
  std::vector<Coord> points;
 public:
  Polygon(std::string s, std::initializer_list<Coord> = {});  // constructor
  ...
  virtual ~Polygon() = default;  // OOPS: don't do that because it disables move semantics
};

However, without declaring the destructor, move semantics works for both Polygon members, name and points. Consider the following program:

#include "geoobj.hpp"
#include "polygon.hpp"

int main()
{
  Polygon p0{"Poly1", {Coord{1,1}, Coord{1,9}, Coord{9,9}, Coord{9,1}}};
  Polygon p1{p0};             // copy
  Polygon p2{std::move(p0)};  // move

  p0.draw();
  p1.draw();
  p2.draw();
}

This program has the following output:

polygon '' over
polygon 'Poly1' over (1,1) (1,9) (9,9) (9,1)
polygon 'Poly1' over (1,1) (1,9) (9,9) (9,1)

For both members, name and points, the values were moved from p0 to p2.

Note that if you have to implement the move constructor in class Polygon, you need special care to provide the right noexcept condition.

4.5 Summary

• Avoid objects with names.
• Avoid unnecessary std::move(). Especially do not use it when returning a local object.
• Constructors that initialize members from parameters, for which move operations are cheap, should take the argument by value and move it to the member.
• Constructors that initialize members from parameters, for which move operations take a significant amount of time, should be overloaded for move semantics for best performance.
• In general, creating and initializing new values from parameters, for which move operations are cheap, should take the arguments by value and move. However, do not take by value and move to update/modify existing values.
• Do not declare a virtual destructor in derived classes (unless you have to implement it).

5. Overloading on Reference Qualifiers

This chapter discusses overloading member functions for different reference qualifiers. As we will see, this will answer the common community question about whether getters should return by value or by constant reference.

5.1 Return Type of Getters

When implementing getters for members that are expensive to copy, before C++11 we had the following alternatives:

• Return by value
• Return by lvalue reference

Let us discuss these alternatives briefly.

5.1.1 Return by Value

A getter returning by value would look like this (remember: do not return by value using const otherwise you disable move semantics):

class Person
{
 private:
  std::string name;
 public:
  ...
  std::string getName() const {
    return name;
  }
};

This code is safe, but each time we ask for the name, we might copy the name.

For example, just checking whether we have a person with an empty name would have significant overhead:

std::vector<Person> coll;
...
for (const auto& person : coll) {
  if (person.getName().empty()) {   // OOPS: copies the name
    std::cout << "found empty name\n";
  }
}

If you compare this approach with an approach that returns a reference, you can see that the version that returns the string by value has a performance overhead of a factor between 2 and 100 (provided the names have a significant length so that SSO does not help). Giving access to a member that is an image or a collection of thousands of elements might be even worse. In that case, getters often return by (const) reference to improve the performance.

5.1.2 Return by Reference

A getter returning by reference would look as follows:

class Person
{
 private:
  std::string name;
 public:
  ...
  const std::string& getName() const {
    return name;
  }
};

This is faster but somewhat unsafe because the caller has to ensure that the object the returned reference refers to lives long enough. In fact, there is a lifetime risk that you use the return value of the getter longer than the object you call the getter for.

One way of falling into this trap is to use the range-based for loop as follows:

for (char c : returnPersonByValue().getName()) {  // OOPS: undefined behavior
  if (c == ' ') {
     ...
  }
}

Note that on the right side in the header of the loop there is a function that returns a temporary object that we refer to with our getter. However, the range-based for loop is defined so that the code above is equivalent to the following: